http://qs321.pair.com?node_id=379262


in reply to Re^5: Automatic stack traces for warns and dies
in thread Automatic stack traces for warns and dies

It doesn't?

You had me there for a second, I couldn't understand how I'd messed that up until I realised that you'd swapped foo(). In the original second example foo() threw an object and when confess gets an object it does not produce a stack trace. Just stick a foo() on the end of the original example and you'll see what I mean.

But this is dealt with by perl, so even with die and warn overridden the value of $^S will be unaffected.

I wasn't talking about changing or not changing $^S. The point is that the die handler should do nothing when $^S is true as this die will be captured by an eval and so adding a stack trace could cause trouble. The only time it should add a stacktrace is when $^S is false. confess does not check $^S, diagnostics.pm does.

"die/warn handlers" was probably the wrong phrase, maybe "similar mechanisms" is more correct. Aristotle's code has no effect on the $SIG things. So the question is, "how does it get on with other modules that override *CORE::GLOBAL::die?" and the answer is "not at all". It could be made to but that's not the point, I'm trying to find a module where all that trickiness has been taken care of.

Also, using subs to localise to a particular package is not acceptable. The goal is to find something which requires no alteration of the source code whatsoever.

diagnostics.pm is about 10 lines away from being exactly what I want. Hopefully you'll be able to do

perl -Mdiagnostics=-t some_broken_script
and it'll just work, with no caveats like "be careful with this kind of exception handling" etc.