Re: Weirdness with $SIG{__DIE__} (and __WARN__)

[Adam]

I'm not sure I understand what you mean by:

The way it steps over previous signals, the way you can't do 'local $SIG{__DIE__}' at the top of your module and get what you want, etc.

You can use local with $SIG{__DIE__}, you just need to assign the local %SIG value to 'DEFAULT' or some handler.

[Anonymous Monk]

Actually, I'm not sure I should have mentioned local. I think 5.6's our declaration is actually closer. But anyway, try this:

in A.pl

package A;

use Z;

$SIG{__DIE__} = sub { die 'in ' . __PACKAGE__ };

eval { die };
print "$@";
eval { Z::Zdie };
print "$@";

and in a separate file (Z.pm):

package Z;

$SIG{__DIE__} = sub { die 'in ' . __PACKAGE__ };

sub Zdie { die }

You'll get this output:

in A at A.pl line 5.
in A at A.pl line 5.

A's signal handler is the one that is used for both deaths.

The reason I mentioned local is that some people try using local to 'fix' this (I know its not a bug) so that the each package could declare signal handlers.

Now change the top of A.pl to this:

package A;

use Sig::Lexical::Paranoid;

use Z;

$SIG{__DIE__} = sub { die 'in ' . __PACKAGE__ };

You'll get this:

in A at A.pl line 7.
in Z at Z.pm line 3.

Note that despite the fact that A assigned directly to $SIG{__DIE__}, it did not overwrite Z's signal handler

This may be useful.

- dave

[tye]

Some consider $SIG{__DIE__} to be broken in design. Certainly, if you want nested 'die catchers' I think you would be better off using eval than $SIG{__DIE__}.

The p5p e-mail list archives have several discussions regarding this.

        - tye (but my friends call me "Tye")

[autarch]

Yes, this 'brokenness' is what this code is intended to address.

This is entirely orthogonal to the use of eval. $SIG{__DIE__} is still useful if you want to convert Perl's run time error deaths into a specific exception object or something.

-dave