Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Always Follow Up on Warnings

by buckaduck (Chaplain)
on Feb 07, 2002 at 20:05 UTC ( [id://143961] : perlmeditation . print w/replies, xml ) Need Help??

Once again I am struck by how true it is, that a good programmer should always follow up on warnings.

I'm writing a DBI program with a CGI interface. The program reads information from the database, performs some transformations, and puts the result into an HTML table. Easy.

But my database has a number of NULL values. This didn't cause any problems in the HTML output, it just made Perl generate a hundreds of annoying warnings about the "use of an uninitialized value". (When using "warnings", of course.) I'll admit that I always used to hate this warning -- after all, I didn't really care if the values were defined or not, as long as the output looked okay.

I initially intended to turn off the warnings, at least in a small block around my string-handling code. But there was this little nagging voice in my head that said, "Make your program run clean under 'use warnings' and 'use strict'". I'm pretty sure that I got this voice from Perl Monks.

And so I spent thirty minutes finding all of the places where the data could possibly be NULL, and I made sure they were defined, like this:

$string = "" unless defined($string);
This got rid of most of the warnings, but there were more. Whoops, I missed a few NULLs. Thirty minutes later I was sure that I had tracked them all down, so I ran the program again. Now, my hundreds of warnings were down to about five.

So I spent another thirty minutes trying to find a place in my code where I could still be getting undefined values. And what did I find? A very real problem with my database. There were NULLS in fields where there shouldn't have been -- where I was absolutely positive that there weren't any. I hadn't even thought to double-check it before.

I've fixed my database, and the program runs clean now. And I am very glad that I didn't turn off warnings, even for one seemingly innocent line of code.


Replies are listed 'Best First'.
Re: Always Follow Up on Warnings
by blakem (Monsignor) on Feb 07, 2002 at 20:58 UTC
    I've been known to rant about uninitialized warnings before... Here is one nice idiom for "cleaning" a series of undefined values.
    $_ = '' for grep !defined, ($x,$y,$z);
    Try the following code with and w/o this clensing line:
    #!/usr/bin/perl -wT use strict; my ($x,$y,$z) = (undef,'hello',undef); # undef "clensing" idiom $_ = '' for grep !defined, ($x,$y,$z); print "x='$x' y='$y' z='$z'\n";


        The problem with $_ ||= '' is that it turns 0's into ''. defined is much less cool, but definitely more effective.


Re: Always Follow Up on Warnings
by Biker (Priest) on Feb 08, 2002 at 09:11 UTC

    You've learnt something important. It's true for any (all?) software development. A warning is a warning and should be respected. There's a reason for it.

    Concerning your specific situation, I use the following snippet, written to give the same appearance as does graphical database tools, like SQL Advantage, Cast Workbench and many others. It's just an idea that works in my situation. Copy it and modify it for your specific needs.

    sub nullify_array { for(@_) { $_='(null)' unless(defined()); } @_; }
    Everything will go worng!

Re: Always Follow Up on Warnings
by gav^ (Curate) on Feb 08, 2002 at 07:46 UTC
    I've always had issues with that warning, especially as I don't like to write:
    if ($x && $x eq 'blah') { ...
    if ($x eq 'blah') { ..
    should do.


Re: Always Follow Up on Warnings
by weini (Friar) on Feb 12, 2002 at 13:38 UTC
    Hi buckaduck,
    you and the monks answering your meditation really made my day - thank you!!!

    Indeed I had exactly the same problem of getting lots of warnings after a db-query. And I was tempted to switch warnings off too.

    The best thing I could do was surfing 'round in the Monastery - I got my solution and I promise never ever being tempted again ... as far as -w is concerned ;^)