in reply to Can't use an undefined value as a HASH reference

It means that this part of that line:  @{ $tree->{children} }[ 0 ], which is the first element of an array, pointed at by the value of the element of the hash, pointed to by $tree, and keyed by the string 'children'; is undefined -- ie. has not been set -- thus when the code tries to use that undefined value as a hash reference ->{label}, you get the error message.

All of which probably won't help you at all if you don't know Perl; even if you have some experience of other programming languages.

What you will need to determine is whether:

  1. the code that build the tree is in error and is failing to construct the tree correctly;
  2. Of if the calling code is in error; by unconditionally expecting that array element to contains a hash reference that contains a key: label.

And the first part of making that determination would be to inspect the source data from which the tree is constructed, and work out whether the undefined value should be set or not.

If, it should, then the code that constructs the tree will need correcting; if it shouldn't, the the attempt to access the undefined value should be made conditional.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Replies are listed 'Best First'.
Re^2: Can't use an undefined value as a HASH reference
by Anonymous Monk on Aug 25, 2015 at 16:06 UTC

    Ok, yeah, gives an idea. Below is a portion of the build_tree() subroutine.

    sub build_subtree {
  my ($line,$lexicon) = @_;

  # minimal sanity check
  if ($line !~ /^\(.*\)\s*$/) {
    return undef;
  }

    [download]

    And $line is: 1 , 4885

    It's not passing the sanity test.

[reply]
[d/l]

      In that case, you could make either of two changes:

      1. Modify the sanity test to die if the input data is malformed.
      2. Modify the failing code to test for undef before attempting to dereference the hashref.

      But there is the school of thought termed the robustness principle, that goes Be conservative in what you send, be liberal in what you accept.

      I would do both: make the sanity test issue a warning (with file line number) and then return undef; and add a test for undef before dereferencing.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

        But there is the school of thought termed the robustness principle, that goes Be conservative in what you send, be liberal in what you accept.

        I definitely prefer 'Be conservative in what you send, be conservative in what you accept.' I hold the opinion that trying to be liberal with input (especially: trying to fix malformed input) is pretty much guaranteed to lead to a bug somewhere later on.

        @OP: Both of the suggestions BrowserUK gave are good. But trying to apply the robustness principle (-> be liberal in what you accept) and automagically initialize a hash reference may sound like a good idea at first but can turn out to be a bad one.

[reply]

In Section Seekers of Perl Wisdom