UPDATE: More to the point, these profiler subs will be called recursively. There will be a stack of profiler subs equivalent to the normal Perl call stack. How can I use $SIG{__DIE__} in a case where multiple subs need to be ready to catch die()s?

Of course, I may just be clinging irrationally to the idea that this is a hard problem just to save myself from realizing I'm a manual-ignoring moron...

-sam

A little experimentation and reading will get you a long ways. You don't die in a DIE handler, recursion is bad. You exit, or you don't, it's your call. But those are your two options, eval or $SIG{DIE}.

>Won't that cause problems with evals in the code being called?
Could you rephrase the question? It's not exactly clear what you mean there.

--
perl -pew "s/\b;([mnst])/'$1/g"

Mid-air collision of update and reply! Eee gads. Ok, I see what you mean about not needing to die() from &$SIG{__DIE__}. (Although, BTW, this recursion isn't "bad" - it's actually recommended in the die() docs as the way to change the error message!)

But I think my concern about the call stack still stands. How can a single global handler be enough?

UPDATE: To clarify, here's an example of how $SIG{__DIE__} doesn't behave the way I think I would need it to:

sub catcher {
    local $SIG{__DIE__} = sub { print "Caught 1!\n"; };
    catcher2();
}

sub catcher2 {
    local $SIG{__DIE__} = sub { print "Caught 2!\n"; };
    sub_that_dies();
}

sub sub_that_dies {
    die "Foo";
}

catcher();
[download]

Now, I'd like that code to print both "Caught 1!" and "Caught 2!". But what it actually does is less useful:

$ perl bomb.pl 
Caught 2!
Foo at bomb.pl line 30.
[download]

Does that make it clear what I mean?

-sam