pascaldee has asked for the wisdom of the Perl Monks concerning the following question:

One of my current rants with Perl is this particular warning: "Use of uninitialized value in foo at line 123". The problem is, I often build multiline expressions involving many variables (usually in string concatenation or interpolation), and Perl doesn't tell me which variable(s) is/are at fault. Can something be done with this?

Replies are listed 'Best First'.
Re: Use of uninitialized value in ...
by almut (Canon) on Feb 22, 2008 at 22:32 UTC

    Sometimes, using a newer version of Perl helps. E.g. 

    use strict;
use warnings;

my $x = "";
my $y;
my $z = "Z";

if ($x =~ /X/ or $y =~ /Y/ or $z =~ /Z/) {
    print "cond true\n"
}

    [download]

    Perl 5.8.8 

    $ ./669664.pl
Use of uninitialized value in pattern match (m//) at ./669664.pl line 10.
cond true

    Perl 5.10.0 

    $ ./669664.pl
Use of uninitialized value $y in pattern match (m//) at ./669664.pl line 10.
cond true
[reply]
[d/l]
      Amazing! :-) Can't wait to use 5.10...
[reply]
Re: Use of uninitialized value in ...
by Your Mother (Archbishop) on Feb 22, 2008 at 22:34 UTC

    I use this in CGIs pretty often because even testing them throws the warning. If you know your vars will be okay because you're checking them yourself or if it's okay if they're missing, it's harmless.

    no warnings "uninitialized";

    Also any concat longer than two lines is probably a style mistake. If it's hard to read (by hard to read, I mean hard for the next developer who has to work with it to read), it's not good style and that would be a good segue into one of my current rants with other developers... oh, look at the time.

[reply]
[d/l]
Re: Use of uninitialized value in ...
by tilly (Archbishop) on Feb 22, 2008 at 22:30 UTC
    You are free to patch Perl to fix this.

    However the problem is that the code which builds the string and finds the uninitialized variable has just been passed pointers to the variables, and not the names. Therefore it really doesn't know the name. Obviously the names of the potential variables are known at compile time, but they are not passed around in the compiled code. (Doing so would make data structures larger and slower.)

    If you really wanted to get ambitious you could create a WARN handler that catches the warning and tries to figure out the variable in question. It could look at the warning, attempt to peek at the Perl source (I don't know where that is stored internally, but I'm sure it is in memory somewhere), and use PadWalker to go poking around and try to figure out the variable that caused the error. However to date nobody has gotten irritated and ambitious enough to tackle that project.

    (If you did do that, then I'd suggest that you sign up for a CPAN account and put it on CPAN. There are people who would find that very useful...)

[reply]
      You are free to patch Perl to fix this.

      Dave Mitchell fixed it in Perl 5.10.

[reply]
        He did? Cool! I should keep up with these things more closely.
[reply]
      You are free to patch Perl to fix this.

      Sorry, this is a really old post, but this REALLY pisses me off. This is exactly the kind of response that gives our community a reputation of being a bunch of self righteous neck beards that take every possible opportunity to feel superior to those less experienced us. It's pretty unlikely that if he had the skill to fix this in Perl, he'd be asking this question on this forum. He wasn't being disrespectful, and unless you're enough of an egghead to have never gotten frustrated, respectfully expressed that frustration and asked for help, but instead patched the offending compiler/interpreter, you should probably keep comments like that to yourself.

[reply]

Back to Seekers of Perl Wisdom