in reply to Error Handling in Object-Oriented Perl

How does your $@ get reset in your destructor? ( I assume you're talking about DESTROY() )

If it's just a simple matter of $@ being reset because of something you do in DESTROY, I think this is all you need (which is similar to what I recently experienced):

sub DESTROY { local $@; ... your cleanup code... }

If not, I think we would need more context...

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

    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.

      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.