|The stupid question is the question not asked
Always Follow Up on Warningsby buckaduck (Chaplain)
|on Feb 07, 2002 at 20:05 UTC
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:
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.