You are passing an undef into a module that has an unstated (and there is the issue) requirement that the value passed in is not undef.

No. A module provides a sub that needs to be passed a string and a number. I pass in undef() for the string and I pass in '42mph' for the number. Those are fine values because I intentionally didn't turn on warnings. But values get passed in to subs as scalars, not as strings or a numbers, so it is inside of the sub that these scalar values get interpreted as a string and as a number. The module's author followed "best practices" (or "cargo cult") and so added "use warnings;". So I get warnings that I didn't ask for and that I don't want.

If I wanted to jump through extra hoops to avoid being warned about the nature of these values, then I would have turned on warnings.

So I prefer to not "use warnings" in my modules (and to use "-w" in my module tests and even to test that no warnings are emitted in my module tests).

In a tool that non-technical people will run, I don't use "-w" (because warnings usually do more harm than good when shown to non-technical people). In most other scripts, I use "-w" and am sometimes glad that I got told about warnings that happened inside of some module (that I didn't write but that still didn't do "use warnings;").

"use warnings" didn't actually solve the problem of "getting unwanted warnings from modules". It just shifted the problem.

If I was forced to frequently use a module that generates warnings internally (not just from values I pass in), I'd likely add a $SIG{__WARN__} hook to suppress such and continue to use "-w" (if I was unable to institute a deploy step that adds "no warnings" to each new version of that module), at least so I could continue to get warnings from any non-problematic modules that didn't "use warnings;".

Others may choose to use "-X" to deal with unwanted warnings from modules that include "use warnings". Since warnings so often follow data, I find tying warnings to blocks of code to just not be a great approach.

I find tying warnings to blocks of code to just not be a great approach.

I'm following this thread with interest; and no firm conclusions yet. (And I just read your follow up.)

And I have an assertion/question/dunnu: Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data?

Currently I favour -w in scripts and use warnings in modules.

I prefer -w explicitly because it let's me see warnings generated as a result of what I've passed to (other people's) modules I use -- when that is the cause -- and prompts me to check up on warnings the authors have ignored; where these occur at use time; and satisfy myself of their benign status or otherwise.

I like to see use warnings in modules (in preference to nothing), because it indicates to me the author has thought about it. I have no problem with no warnings at limited scopes.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data?

Either that, or the purpose of the code creating that data.

Enabling or disabling some warnings at some localized scope can certainly be useful. The short-comings of warnings.pm are only partial.

You could repair some of the shortcomings of warnings.pm by allowing subs to declare that they want string values or numeric values (well, for positional arguments), such that the conversion from scalar to string/number would happen in the context of the call to the sub rather than inside the sub when the arguments are extracted or even later when they are finally put to real use.

You could also repair them by providing a way for a sub to request code to be run with the caller's warnings settings. Then a careful module author could go to the effort to "cast" any provided values to the more-specific type in a way that would only cause a warning if the caller wanted to hear that type of warning.

sub careful {
    my( $string, $number ) = @_;
    {
        use warnings ':caller';
        $string = "$string";
        $number = 0+$number;
    }
    ...
}
[download]

You could also put the onus on the author of the calling code. This doesn't make much sense to me in the case of the caller not wanting warnings, but I can see it making sense when the caller wants warnings but the called sub doesn't have warnings enabled:

use warnings;
    ...
    sloppy( "$string", 0+$number );
[download]

These relatively few data-specific warnings might be rather insignificant if it weren't for the fact that "uninitialized" warnings are probably the single most common warning both in terms of how likely they are to happen and in how often people want to ignore them.

Though, I'm not advocating for such feature enhancements to Perl. I'm happy with my "-w" and (newly adopted) "-X".

- tye        

Thanks for the question. This eventually made me realize that I should update my practices.

I will continue to mostly use "-w" in scripts because I almost never have problems with modules producing unwanted warnings that I can't avoid. I will also continue to use "-w" in my module tests. But, for scripts where warnings are not useful, I will use "-X" and thus avoid being impacted by modules doing "use warnings" and enabling warnings that I don't want.

And I will be putting "use warnings;" in all of my modules, as this serves as an imperfect but still useful indication that they are modules that have been tested with warnings enabled and so are at least relatively unlikely to be one of those modules that generates unwanted warnings. This will allow people like MidLifeXis to benefit from (presumably useful) warnings from my modules without having to resort to "-w", which would be a problem due to his need to use vendor modules that aren't "warnings safe".

- tye