Re: Best Practices for Exception Handling

in reply to Best Practices for Exception Handling

Another way of treating an error or warning as an event (which I have only learned a while ago and found useful) is to define handlers for it using:

local $SIG{__WARN__} = \&HandlerSub;
local $SIG{__DIE__} = \&OtherHandler;
[download]

But the problem with it is that you really must pay attention to your use of warn and die, as well as conditions when something not written by you might die.

Comment on Re: Best Practices for Exception Handling Download Code

Replies are listed 'Best First'.
Re^2: Best Practices for Exception Handling by adrianh (Chancellor) on Jul 11, 2003 at 18:24 UTC
There are problems when you mix the signal handling style with other modules that use exception handling, or use it in persistent environments like mod_perl so (in my opinion) it is best avoided. Alternative Exception Handling Techniques in the mod_perl guide has more info on this. Also see the documentation on `$^S` (in perlvar) and die. It's often simpler just to override `CORE::GLOBAL::die` and `CORE::GLOBAL::warn`.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Best Practices for Exception Handling
by adrianh (Chancellor) on Jul 11, 2003 at 18:24 UTC

There are problems when you mix the signal handling style with other modules that use exception handling, or use it in persistent environments like mod_perl so (in my opinion) it is best avoided.

Alternative Exception Handling Techniques in the mod_perl guide has more info on this. Also see the documentation on $^S (in perlvar) and die.

It's often simpler just to override CORE::GLOBAL::die and CORE::GLOBAL::warn.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom