{"id":45,"date":"2003-11-24T10:44:45","date_gmt":"2003-11-24T14:44:45","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/rlucastemp\/2003\/11\/24\/fix-suppress-perl-uninitialized-va"},"modified":"2003-11-24T10:44:45","modified_gmt":"2003-11-24T14:44:45","slug":"fix-suppress-perl-uninitialized-value-warnings-strongish-medicine-f","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/rlucastemp\/2003\/11\/24\/fix-suppress-perl-uninitialized-value-warnings-strongish-medicine-f\/","title":{"rendered":"FIX: Suppress Perl “uninitialized value” warnings (strongish medicine for clueful users only)"},"content":{"rendered":"

<\/a><\/p>\n

If you have written any Perl of moderate complexity, and especially<\/EM> if your Perl of moderate complexity has included CGI and Database interactions, (or any time you have to deal with undef<\/CODE> or NULL<\/CODE> vs. a blank string, and you might have either of the two), you have run across warnings like this (maybe to STDERR, or maybe in your \/etc\/httpd\/logs\/error_log):<\/P>
\n

Use of uninitialized value in concatenation (.) or string at …<\/CODE><\/P>
\n

Use of uninitialized value in numeric gt (>) at …<\/CODE><\/P>
\n

etc.  How can you stop these error messages (warnings, really) from blocking up your logs and your STDERR?<\/P>
\n

In fact, you should be somewhat concerned at your uninitialized value<\/CODE> warnings.  After all, they are there for a reason.  A really<\/EM> good piece of code ought not to generate them, at least in theory.  However, sometimes you want the benefit of use strict<\/CODE> and -w<\/CODE> warnings, and you have at once good reason not to want to know about uninitialized values.  What might these be?<\/P>
\n