Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^2: determine the variable causing the error: Use of uninitialized value

by ruqui (Acolyte)
on Apr 13, 2017 at 19:34 UTC ( #1187871=note: print w/replies, xml ) Need Help??


in reply to Re: determine the variable causing the error: Use of uninitialized value
in thread determine the variable causing the error: Use of uninitialized value

Rolf, I'm aware of the solution you proposed, but it is unpractical for me, most of the times I'm dealing with large hash structures and big input data, it's inefficient to initialize everything just to avoid an error; in fact, I'm usually don't even want to supress the error (this usually means the input data is wrong and I need to deal with it), I just want a quicker way to determine which variable is involved.
  • Comment on Re^2: determine the variable causing the error: Use of uninitialized value

Replies are listed 'Best First'.
Re^3: determine the variable causing the error: Use of uninitialized value
by AnomalousMonk (Bishop) on Apr 14, 2017 at 00:04 UTC
    ... I'm dealing with large hash structures and big input data ... I'm usually don't even want to supress the error (this usually means the input data is wrong and I need to deal with it) ...

    The point raised by haukex here is critical: you're really dealing with input data validation, not a way to flag the use of an undef value that might be present if your input data was invalid. In other words, don't bother trying to lock the barn door after the horse has bolted. The ideal time to deal with bad data is when you get it, not after it's drifted downstream and had a chance to gum up other processes.

    The only way I can think of to validate a data structure is to write a validation function specific to that structure and invoke it as soon as possible after the structure is captured:
        my %bigdata = capture_big_input_data($inputstream);
        validate_bigdata(\%bigdata);
    Obviously, the bigger your data, the bigger your validation job, but that's life. (You may even decide that certain missing data fields can, in fact, be fixed up with a zero, an empty string or whatever; if so, the  validate_bigdata() function is the ideal place to do this patching.)

    The other variation on this theme is when you read your input data on a line-by-line or block-by-block basis. In this case, you must figure out a way to validate each line or block as it is read — at least, that's what I would do. Anyway, you get the idea...


    Give a man a fish:  <%-{-{-{-<

      Thank you for the advice, but your suggested approach is highly inefficient and not useful at all in my situation.

      Also (and more important), I think you're missing the point :), I'm not looking for any type of methodology to circumvent or prevent the error from happening, I just want to know if it's possible (without writing any specific checking code) to know the name of the variable that produces the error:

      Use of uninitialized value in print...

        ... your suggested approach is highly inefficient and not useful at all in my situation.

        Of course, I have no idea what your situation is, but my post was motivated by the conviction that some measure of data validation is essential in any data processing application, however time-consuming it may be.

        ... I'm not looking for any type of methodology to circumvent or prevent the error from happening ... [is it] possible (without writing any specific checking code) to know the name of the variable that produces the error ...

        But if you're not going to prevent or handle the warning in any way, what do you care about the name of the variable? Just suppress the warning.

        But again, you know your business best...


        Give a man a fish:  <%-{-{-{-<

        The best way to figure out which variable caused the warning, in situations where the warning message itself doesn't already show you the variable name, is to check for the warning condition before the warning occurs -- which is what's been described to you already.

        Alternatively, break up the single printf into multiple printf's, each only printing one variable -- then whichever line number the warning occurs on will tell you unambiguously which variable was the culprit, because it's the only possible variable on that line. Alternatively, use 5.010; and change printf "will warn: x=|%s| y=|%s| ha=|%s| hb=|%s|\n", $x, $y, $h{a}, $h{b}; to printf "will id:   x=|%s| y=|%s| ha=|%s| hb=|%s|\n", $x//"<undef>", $y//"<undef>", $h{a}//"<undef>", $h{b}//"<undef>"; -- by using the //"<undef>" and including the variable name before each portion of the print, any variable that is uninitialized (ie, undefined), will show up as "<undef>". Alternatively, use a debugger (perl -d, or your favorite IDE) to manually find where the error occurs. Alternatively, make a wrapper function for printf, and manually check all arguments for undefinedness (you could even wait until after the printf, so you still get your warning, if you so desire.

        #!perl use warnings; use strict; use 5.010; # required for // my %h = (a=>undef, b=>2); my ($x,$y) = (undef, 'why not'); warn "-"x20, __LINE__, "\n"; printf "will warn: x=|%s| y=|%s| ha=|%s| hb=|%s|\n", $x, $y, $h{a}, $h +{b}; warn "-"x20, __LINE__, "\n"; printf "will id: x=|%s| y=|%s| ha=|%s| hb=|%s|\n", $x//"<undef>", $y +//"<undef>", $h{a}//"<undef>", $h{b}//"<undef>"; warn "-"x20, __LINE__, "\n"; sub dbg_printf { printf @_; for my $i ( 0 .. $#_ ) { my @ord = qw(th st nd rd th th th th th th); warn ">> it was the ${i}" . $ord[$i%10] . " argument to dbg_pr +intf() that was not defined \n" unless defined $_[$i]; } } warn "-"x20, __LINE__, "\n"; dbg_printf("will warn, but expand: x=|%s| y=|%s| ha=|%s| hb=|%s|\n", $ +x, $y, $h{a}, $h{b}); warn "-"x20, __LINE__, "\n";

        To sum up: to debug a warning, if the warning message is not sufficient to tell you where the problem is, you will have to write some checking code and/or use a debugging environment.

Re^3: determine the variable causing the error: Use of uninitialized value
by haukex (Bishop) on Apr 13, 2017 at 19:52 UTC
    I'm usually don't even want to supress the error (this usually means the input data is wrong and I need to deal with it)

    If it's undefs in a Perl data structure that you seek...

    sub seek_undef { my ($ref,$path) = (@_,""); if (ref $ref eq 'HASH') { seek_undef($ref->{$_}, $path."{$_}") for keys %$ref } elsif (ref $ref eq 'ARRAY') { seek_undef($ref->[$_], $path."[$_]") for 0..$#$ref } else { defined $ref or warn "undef at $path\n" } } seek_undef( { foo => { quz=>{ abc=>"def", ghi=>undef } }, bar => { baz=>[ "jkl", undef, { ooo=>undef } ], blah=>undef }, uuu => undef, } ); __END__ undef at {foo}{quz}{ghi} undef at {bar}{baz}[1] undef at {bar}{baz}[2]{ooo} undef at {bar}{blah} undef at {uuu}
Re^3: determine the variable causing the error: Use of uninitialized value
by LanX (Sage) on Apr 13, 2017 at 20:30 UTC
    OK I was able to reproduce (some of) your problems in 5.14 ... that's indeed pretty inconsistent.

    As a first step we should check if newer versions still have these problems.

    use strict; use warnings; warn "version $]"; my %hash=(a=>undef,b=>[]); my $h=\%hash; my @array=({a=>undef}); my $a=\@array; warn "hash $hash{a}"; warn "hoa $hash{b}[0]"; warn "hashref $h->{a}"; warn "hoa ref $h->{b}[0]"; warn "array $array[1] "; warn "aoh $array[0]{a} "; warn "array ref $a->[1] "; warn "aoh ref $a->[0]{a} ";

    version 5.014002 at /home/lanx/pm/warn_undef.pl line 4. Use of uninitialized value $hash{"a"} in concatenation (.) or string a +t /home/lanx/pm/warn_undef.pl line 13. hash at /home/lanx/pm/warn_undef.pl line 13. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 14. hoa at /home/lanx/pm/warn_undef.pl line 14. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 16. hashref at /home/lanx/pm/warn_undef.pl line 16. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 17. hoa ref at /home/lanx/pm/warn_undef.pl line 17. Use of uninitialized value $array[1] in concatenation (.) or string at + /home/lanx/pm/warn_undef.pl line 19. array at /home/lanx/pm/warn_undef.pl line 19. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 20. aoh at /home/lanx/pm/warn_undef.pl line 20. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 22. array ref at /home/lanx/pm/warn_undef.pl line 22. Use of uninitialized value in concatenation (.) or string at /home/lan +x/pm/warn_undef.pl line 23. aoh ref at /home/lanx/pm/warn_undef.pl line 23.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

      tested in 5.22 with same results

      version 5.022000 at pm/warn_undef0.pl line 4. Use of uninitialized value $hash{"a"} in concatenation (.) or string a +t pm/warn_undef0.pl line 13. hash at pm/warn_undef0.pl line 13. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 14. hoa at pm/warn_undef0.pl line 14. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 16. hashref at pm/warn_undef0.pl line 16. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 17. hoa ref at pm/warn_undef0.pl line 17. Use of uninitialized value $array[1] in concatenation (.) or string at + pm/warn_undef0.pl line 19. array at pm/warn_undef0.pl line 19. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 20. aoh at pm/warn_undef0.pl line 20. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 22. array ref at pm/warn_undef0.pl line 22. Use of uninitialized value in concatenation (.) or string at pm/warn_u +ndef0.pl line 23. aoh ref at pm/warn_undef0.pl line 23.

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

Re^3: determine the variable causing the error: Use of uninitialized value
by karlgoethebier (Abbot) on Apr 14, 2017 at 15:13 UTC
    "...it's inefficient to initialize everything..."
    "Everything has it's price" (Thomas Mann)

    «The Crux of the Biscuit is the Apostrophe»

    Furthermore I consider that Donald Trump must be impeached as soon as possible

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1187871]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2022-07-04 15:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?