* Abelard <abelardhoff...@gmail.com> [2016-09-12 08:36]:
> The difference being that before we call the original die handler,
> we reassign SIG{__DIE__} back to it, which I guess re-enables the
> recursive call protection.

Ah, makes sense. But there’s no mechanism that restores your own die
handler, is there? It seems to me this this will only ever modify one
exception – if it happens to be the one you wanted, great, otherwise,
not so great.

The only solution I could think of is a bit crazy: store a scope guard
in @_ which restores your die handler on DESTROY.

A less crazy solution might be here:
Looks like the die handler implements the recursion check manually.

Another option is to not use the `goto` and just call $old_die_handler
normally. That works reliably as long you *know* that $old_die_handler
will call `die` (which happens to be the case here) instead of trying
to abandon the exception using `goto`.

If it does try to abandon the exception, you must call it with `goto`
also, otherwise it will not succeed. But as long as it never tries to
`die`, that’s fine, so that works too.

So I suppose this is solvable as long as you expect a particular die
handler in %SIG and pick the matching approach. But I’m not sure one
can chain die handlers generically.

Aristotle Pagaltzis // <http://plasmasturm.org/>


You received this message because you are subscribed to the Google Groups 
"psgi-plack" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to psgi-plack+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to