Signals and local $@

[Rainer Weikusat]

[...]

I also don't quite understand why one would localize $@ and want to
propagate errors out of the scope of the local at the same time. The
easy way to accomplish that would be not localizing $@ to begin with.

I'd like to add that I've meanwhile found a reason for doing this: I
tend to do 'stuff' from DESTROY methods, eg, using a class to
represent some kind of 'externally visible event' and 'sending' that
'event' (usually in form of a message sent via some socket) from the
class destructor. Because of this, code running from a destructor
might run into supposed-to-be-fatal runtime errors caused by something
which is external to perl, eg, the kernel. This implies that $@ should
be localized in such a destructor to avoid clobbering an exception in
the process of being thrown and that any 'other exception' caused by
code running from the destructor should also affect the program in
case execution continues. It normally wouldn't because perl will eat
any runtime error occuring during destructor exection. My present idea
for dealing with this looks like this:

sub DESTROY
{
local $@;

eval {
$_[0]->XDESTROY();
};

x_push($@) if $@;
}

this being a 'DESTROY' method classes using this facility can
import. It will then invoke the actual class destructor (somewhat
uncreatively named XDESTROY) and push 'an exception which happened
while doing that' onto an array maintained by the 'run loop'
module. Should processing again end up in the top-level event loop,
the most recently added exception in this array will be thrown and so
forth, until the program either terminates or the exception array is
again empty.