Wonderful. A large portion of my environment is used with a vendor's perl library that is not warnings safe. If the landscape has changed in modern perls to the point that warnings no longer 'does the right thing', then here be dragons. :-/

Wait, let me wrap my head around what you are stating.... 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. Wouldn't that be a bug in the modern module (poor spec/docs/defaults) or in your usage of the module? Not saying that your assumption is inappropriate, just that there is a gap between the assumptions of the user and provider of the code.

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.

- tye        

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

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