Sorry I can't offer a quick fix for old messes.

Phil

You're right. On many that I've been fixing I was able to use the line number to fix it, however, this one has me stumped so I intentionally left out the additional info it gives in hopes of finding general answers for how to track them down vs. this specific instance. Though since I've mentioned it now, here's the full message: "Use of uninitialized value in join or string at (eval 39) line 15."

Thanks for the quick response!

You have to figure out what the 39th call to eval is, and look at line 15 in it:

use warnings;
foreach my $i ( 1..5, undef, 7..9 ) {
        eval '$x = join("",$i,"");';
}
# Use of uninitialized value in join or string at (eval 6) line 1.
[download]

If you don't have a good line number, start putting warn statements in the code. Their output will go to standard err just like the uninitialized value warnings, so they will appear in sequence with the problem. By knowing which warns come before and after the one you are tracking, you can locate it.

Phil

Update: corrected to show warn goes to stderr, thanks Hue-Bond.

It's also useful to have those checks in there when something changes with the data and the routine blows up, 6 months down the road.

Both good suggestions (the above and the higher up about finding that certain eval). It seems like if the problem ends up being in a module that's being called it would be MUCH more difficult to track down by putting checks in the local code unless I played the elimination game of removing lines until the problem goes away.

I thought I had read the debugger had a mode that would basically allow me to step through the program and see what happens as it executes. I was hoping I could use something like that to watch for exactly where/what it was complaining about.

Time to visit the friendly manual some more. ;)

use strict;
use warnings;
use Carp;

# Configure the warn signal handler to print the stack trace provided 
+by Carp.
$SIG{__WARN__} = sub {print STDERR Carp::longmess(@_); };

run();

sub run {
    my $code = eval 'sub {
        my $a = 1 - undef;
    };';
    $code->();
}
[download]

Use of uninitialized value in subtraction (-) at (eval 1) line 2.
        main::__ANON__() called at pm564376.pl line 14
        main::run() called at pm564376.pl line 8
[download]

Nice tip! Using that I was able to pinpoint from where the complaint was coming and fix it. It's not the elegant solution I was hoping for, but it worked and the problem's solved so how can I complain? ;)

For those who are interested, here's the offending line of code causing 5MB of that warning:

map{ td({align=>$align->{$_} || $default_align, valign=>$default_valig
+n}, $main_row->{$_}) } @summary_columns;
[download]

Only a couple of thousand more lines like that hidden around this massive system to deal with now. :P

I have seen a lot of examples where the programmer created this problem by not checking return values. He does a call to a system function or a module function then uses the return value without testing for undef or false. These errors can propagate quite a ways through the code through various regexes and other manipulations. No, I don't know of any automated way of checking this. You need to check the documentation for each call for possible return values. Defensive programming is the word here. Every call returning a string or reference should be checked for both undef and null.