[Mastering-perl] Debugging, Profiling, and Cleaning Up Code

[brian d foy]

> "In general, I recommend turning off warnings once a program is in
> production. Turn on warnings when you need to test or debug the
> program, but after that, you don't need them. The warnings will just
> fill up log files."
>
> which I consider.... odd advice :-) The point of log files is to spot
> problems. Warnings are often indications of problems. That's why log
> files filling up with warnings is a /good/ thing. That way you can
> fix the problem!

I should emphasize this in the chapter, but:

Warnings *can be* indications of problems, but not all warnings are.
Once something is in production, you should have already seen all of
the warnings that the code is going to produce and either have fixed
them, turned them off selectively, or decided that you don't care. You
don't want the ones you don't care about cluttering the log files and
diluting the error messages you do care about.

The problem comes in when you release something with warnings turned
on and it appears to be warning clean, then somebody upgrades Perl (or
even a module you didn't write). The latest pumpking has a different
idea about warnings and your code is no longer warning clean.
Unexpectedly, you fill up a disk because every invocation of your
script is spitting out several lines of warnings. You're not even
looking for this because you didn't change the script, but you still
get the page late at night because the script is failing. It's not
really failing: it just can't write to the full disk anymore.

Warnings are a development tool. If you aren't developing and looking
at the warnings, then your log file is just a broken record. :)




-- 
brian d foy <brian.d.foy at gmail.com>
http://www.pair.com/~comdog/