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

[Adrian Howard]

On 11 Oct 2006, at 19:21, brian d foy wrote:
[snip]
> 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.
[snip]

The problem with me for this approach is that "should have". I fear  
that I am an imperfect soul and sometimes fail to anticipate  
everything the code does. When that happens I want to see the warning  
so I can understand what I've missed.

I never don't care about warnings. I either switch them off, or deal  
with the underlying issue causing the warning. When I do this I find  
that any remaining warnings that show up are usually a sign of bugs -  
and I want to see them.

> 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.

My experience has been that moving from a warning clean system to one  
with a bunch of warnings is usually a sign of the code going wrong  
somewhere - so I want to see those warnings so I can fix it.

> 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. :)

My feeling is that if I'm not keeping track of my log files, doing  
log rotation, looking at expected entries, etc. then I'm not doing my  
job properly.

My experience has been that live code with warnings disabled has  
hidden problems, sometimes significant business critical problems, in  
running code. Live code with warnings disabled has become a big red  
flag for me.

It looks like we've had different experiences :-)

Cheers,

Adrian