Signals and local [email protected]


Rainer Weikusat

I also don't quite understand why one would localize [email protected] 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 [email protected] 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 [email protected] 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:

local [email protected];

eval {

x_push([email protected]) if [email protected];

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.


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question