Re: Are There Error Handlers in Perl?

[repson]

People are saying that $SIG{__DIE__} is a bad thing. This is true if die is just used with strings.

However this document at perl.apache.org, despite being written for mod_perl, gives good instructions for the procedure of dieing with objects. This allows you to do this sort of thing:

die My::Exception->SomeException( foo => "bar" );

And then deal with the data SomeException and (foo => 'bar') in the exception class My::Exception.

Or you can overload the die function, allowing other trickery.

[tye]

This is exactly the type of things that I think you should do with eval {}. If you are going to be throwing exceptions then you need to be able to nest your exception catchers. This is exactly how eval {} works.

No matter how tricky you get with saving and queueing $SIG{__DIE__} handlers, you'll never get a $SIG{__DIE__} handler to unwind part of the stack so the third handler up can deal with an exception that the inner two handlers couldn't continue past.

And all you need is one person somewhere setting $SIG{__DIE__} without following your queueing method and you lose.

I get the feeling that $SIG{__DIE__} is much more popular than eval {}. I'm not sure if this is due to wording in the documentation or an overblown fear of "slow eval".

        - tye (and I'll see an end to $SIG{__DIE__} and File::FindBin yet!)

[tilly]

I suspect overblown fears. Folks, read eval and pay close attention to the fact that when you eval a block it is resolved at compile time and it is fast. In fact it should be be both faster and more reliable than throwing and rethrowing signal handlers. (As well as a heck of a lot simpler.)

Oh, you might also pay attention to the suggested use of local $SIG{__DIE__} handlers within an eval as a work around when other people get it wrong. That is slower, but working around other people's mistakes generally is.