* 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: https://github.com/moose/Moo/blob/master/t/demolish-throw.t 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. Regards, -- 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.
