Well, that situation was part of the motivation for the creation of "use warnings". But, I find that this motivation mostly no longer applies and that "use warnings" has its own problems and those are now worse than the problems of "-w" in most environments that I encounter.

For example, it is fairly common to work in a manner where treating undef as either 0 or the empty string is not a problem. In such an environment, I don't enable warnings. But if I use a "modern" module, then it will have turned on warning for itself. When I pass one of these undefs into that module, I'll likely get a warning when the module tries to use that value as a string or as a number.

So, in that case, "use warnings" causes the exact same problem as the one you claim I should avoid by using it.

So I have better luck making sure that I always use "-w" in module tests and that I enable warnings in run-time environments where the warnings won't be useless (or worse). It has been a very long time since I ran into a problem with a module producing unwanted warnings due to my use of "-w". It has not been a long time since I've seen unwanted warnings from "use warnings" in a module.

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.

--MidLifeXis

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