in reply to Re^3: Question on "Effective Perl Programming" (intervene)
in thread Question on "Effective Perl Programming"

If it takes so much to check that an eval worked, maybe something should be fixed?
  • Comment on Re^4: Question on "Effective Perl Programming" (intervene)

Replies are listed 'Best First'.
Re^5: Question on "Effective Perl Programming" (intervene)
by girarde (Hermit) on Sep 08, 2007 at 21:03 UTC
    How is this:
    my $worked = eval {stuff}; if ($worked) { print "Yay!"; } else { print "Boo!: $@"; }

    so much to check an eval? That's all you really need to do.
      "stuff" might return false, but not be an eval error, thus to paraphrase some other post of tye's:
      my $worked = eval { stuff; 1; };
      Of course, then you lose the return value of stuff if you cared about it, though you could save it in another variable if you want to go through the trouble.

      The big problem I have with the behavior that tye illuminates is that you can't tell what the exception was, only that something happened.

        girarde is correct in concluding that Anonymous Monk is completely off base in writing "If it takes so much to check that an eval worked". Adding a 1 and checking directly is a trivial amount of work.

        But there is truth to "maybe something should be fixed".

        Certainly, any module with a DESTROY that uses eval w/o localizing $@ should be fixed. But that also doesn't mean I'll stop protecting myself from such mistakes because fixing them when you find them doesn't mean they won't crop up again in future.

        A patch to Perl that prevented a DESTROY method from clearing $@ would seem prudent to me (you probably want to allow a DESTROY to change but not clear $@ in case someone does that intentionally).

        On a somewhat related point, I'd like to have @@ so that dieing inside of a DESTROY doesn't get lost:

        sub DESTROY { die "No disassemble!" } print "($_)\n" for eval { my $x= bless {}; 1 }, $@; __END__ (1) ()

        - tye