in reply to Re: Error Handling in Object-Oriented Perl
in thread Error Handling in Object-Oriented Perl


Thank you for your quick assistance, lestrrat! Adding local $@; in the destructors protected the $@ value from being reset. I was making logging calls in the destructors which were resetting $@.

I still, however, have lingering questions about best practices for error handling in this circumstance. Is the practice of calling die in the if ($@) {...} block good practice?

I, also, have open-ended issues about comingling error handling and logging. For instance, calling die if $self->fatal("error message"); is called.

Replies are listed 'Best First'.
Re: Re: Re: Error Handling in Object-Oriented Perl
by lestrrat (Deacon) on May 23, 2002 at 22:55 UTC

    I don't know about best practices, but I do this all the time...

    eval { ... } if( my $err = $@ ) { die $err; }

    However, I tend to make my code propagate most of fatal errors all the way up to the user, unless there is some compelling reason that the error must be trapped in that particular level. I trap and re-throw in mostly in cases when I want to add more logging information than $@ would otherwise contain... otherwise I just let it propagate.

    ... and since that "compelling reason" varies from application to application, I don't have a general solution :(

      I think a little more idiomatic construct would be:

      eval { ... } die if $@;
      Which will propagate the $@ (appending "... propagated" if $@ is a string, and calling $@->PROPAGATE() if $@ is an object, and then issuing die $@ (this is only documented from perl 5.6, so it might not work like this on older perls...)

      See also:

      perldoc -f die
      -- Joost downtime n. The period during which a system is error-free and immune from user input.

        Ha! Learn something new everyday ;) thanks for the pointer :)