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

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.

Replies are listed 'Best First'.
Re^3: Can't use an undefined value as a HASH reference
by BrowserUk (Patriarch) on Aug 25, 2015 at 18:03 UTC

    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]
        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.

        Firstly, no where in my post did I suggest: "automagically initialize a hash reference"; so that's a pure strawman.

        I definitely prefer 'Be conservative in what you send, be conservative in what you accept.'

        And on that I absolutely and fundamentally disagree. And I'll go further and say: that attitude (not your's personally; but in general in the industry) has set the industry back by two decades.

        Specifically; the phrase I highlight in your next sentence:

        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.

        That term "malformed input" had almost never appeared in the literature prior to the appearance of the XML standardisation process.

        At last after nearly 20 years, the industry is finally beginning to realise the damage that ill-conceived and misbegotten monstrosity has done and it is now being widely reviled and rejected in favour of simpler, cleaner, more flexible data formats.

        Imagine you've downloaded (or retrieved from a corrupted disk or tape) several gig of (XML) data but its suffered some corruption. Your (the XML) approach would simply reject the whole lot as malformed. End of.

        But maybe that corruption may only affect part of the data that you don't need; or a few hundred records out of millions. A robust and flexible approach will allow your program to get and process most of the data; and report that data which it can't process. The results will often be enough for the purpose; but if they aren't, you at least have a clear record of what is missing and where you need to expend special effort.

        Every now and again, even the best websites construct pages that aren't well-formed. If browsers followed your/the XML approach and simply threw their hands up -- malformed input -- we'd get to see nothing; which would be silly because most of the time, even if the page is slightly or even heavily corrupt in terms of its presentation; the information it contains is still readable; usable.

        The Robustness Principal is well-named; and is not one of those purely theoretical, high-brow principles, but rather the product of practical experience and pragmatism. And it works! TCP/IP would not work without it.

        You reject the pragmatism of your predecessors at your own peril.

        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]

In Section Seekers of Perl Wisdom