I always leave warnings turned on. But then, the majority of the code I write isn't going to be end-user applications. If it isn't strictly for myself, most of the time it's intended for sysadmins or other technical people.

I very much prefer a bug report saying "the program reports 'Use of unintialized value on line 619 of Module.pm'" instead of "the program doesn't work correctly".

Abigail

I think I am looking at this from a different viewpoint than is mentioned here. First, I always leave warnings on in production. I used to make changes between "production" and "non-production" code and later realized how easy it is to miss those changes. So I don't change 'em. If anything, I use config files for those differences.

So what happens when I leave warnings enabled? For one of our applications, we get huge error logs. They are completely ignored until a problem occurs, then we waste a lot of time trying to narrow down which of the entries might match our problem.

I'm working on a new version of this application and one of my goals is to completely eliminate warnings. So far, I've had a test version of the new app running for a month and the only entries in the error log are bad login attempts -- exactly what I wanted. If an app generates spurious warnings, it is crying wolf and programmers will be conditioned to ignore them. If all warnings are eliminated, it makes you sit up and take notice on the rare occassions when one does occur.

One of our shop standards is that all code must run clean under warnings. Follow that standard, leave the warnings on, and if you see something in your logs, there's a very good chance that you really do have a problem.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Furthermore if you are writing modules for others to use then why not use warnings::register and the functionality it provides.

package Foo;
use warnings;
use warnings::register;
sub some_func{
   warnings::warnif("some_func");
   print "some_func() doesnt do much right now....\n";
}
package main;
no warnings;
Foo::some_func();
use warnings;
Foo::some_func();
__END__
some_func() doesnt do much right now....
some_func at C:\Temp\warnings.pl line 12
some_func() doesnt do much right now....
[download]

---
demerphq
my friends call me, usually because I'm late....

Secondarily, I tend to believe that changing as few things as possible between "pre-production" and "production" code is generally smart. It's hard enough to debug problems on code running in an alien environment when the code is bit-for-bit identical to what you're running in your dev or test environment. Why add another variable to the equation if you don't have to. (I know, simply removing 'use warnings' shouldn't cause any problems, but since I don't see much benefit to removing it, why take the chance.)

The idea is then that once your development is done and your program does not generate any warnings any more, they are turned off in the released version. If your code is working according to specs (i.e. it does everything it advertises to do, and it does it in the way that is in the user documentation) and you have robust error handling in place, warnings are no longer necessary according to this school of thought.

The obvious flaws here are of course that: i) no application that is more complicated than Hello World is ever working to specs, ii) no one can foresee every error that can occur let alone test your error handling for it and iii) no application is ever bug free.

Consequently, for the very same reasons Abigail mentioned, I would prefer to leave warnings on. "It doesn't work" just is no fun as a bug report.

CU
Robartes-

()-()
 \"/
  `                                                     

Yes the warnings pragma does require 5.6.


There is the -w flag in earlier releases which
is what I was mostly asking about.
(I am just starting to move to 5.6 now.)

But what effect will a -w flag have if you are releasing a module as opposed to a stand alone script?

()-()
 \"/
  `                                                     

I asked the CEO of a high-tech company whose products are used by a large fraction of you about this issue and why no one was willing to spend any money or effort to fix these problems, and his response was that "the records of our customer service department show very few complaints about software crashes due to buffer overflows and the like". Of course not, you idiot! The software developers turned off all the checks so they wouldn't be bugged by the customer service department!

Of course this relates to buffer overflows, but I see strict, warnings and taint mode as the closest equivalents when working with Perl. There is definitely no excuse ever to turn them off for any nontrivial script in my very strong opinion. Production code should not violate any of these constraints when running smoothly. Any errors you then get indicate a problem you aren't catching properly.

I'd rather my users complain because scripts produce spurious warnings or even bail out as opposed to finding they've been silently throwing sand between the gears. There is no telling how much and how critical data a program that keeps running on bad input is going to mess with.

My policy is that any production code should never try to recover from faults that were not specifically anticipated and error handled. If something looks wrong, even if it's minor, I have my code die screaming. I'd rather look stupid for a few minutes and have to fix a minor oops when the script sticks its tongue at me than have to fix or, horrors, write off corrupt data after the fact.

Makeshifts last the longest.