Re: Throw from within a DESTROY block (bug)

[tye]

Handling throwing from a destructor is "hard". It is very often not done well by an implementing language. This is true for Perl.

What should happen when you die (even indirectly) inside of a DESTROY method is that Perl should catch (and store) the exception and then continue the tear-down of the current scope.

If the current scope was being torn down due to the throwing of a prior exception, then the original exception should continue its progression up to where it will be caught (or just emitted). The during-DESTROY exception(s) should be made available in some way (likely just logged to STDERR but also making them available in something like @@ would be a nice touch -- though perhaps it may be enough or even better to just ensure $SIG{__DIE__} can handle them and also be able to tell them apart from non-DESTROY exceptions).

If the current scope was being torn down because it was exited normally, then once that is done, Perl should simply (re)throw the (first) during-DESTROY exception.

But because properly handling exceptions thrown during scope tear-down is tricky work (not just the details of implementing it well but also the possibility of an unbounded number of exceptions being thrown in the context of a single 'catch' [eval] leading to interesting design conflicts), some people even start thinking that the entire concept of throwing an exception from a destructor is somehow nonsensical and shouldn't be tolerated.

But the wonderful value of DESTROY is that every c'tor (constructor) that succeeds will always be followed by its paired d'tor, which makes it a very valuable tool for the sane handling of tons of things (all manner of resource allocation but also other things that should always be done in pairs, like transactions, reference counting, etc.). And handling tons of things means that you need to be able to deal with that handling going wrong or failing.

Throwing from a d'tor is an important feature and the small extra effort should be invested to support it properly.

Perl used to store during-DESTROY exceptions in $@. But that was a bad idea. Unfortunately, the "fix" chosen for this may be an even worse idea: just completely ignoring during-DESTROY exceptions? I don't have 5.14 handy anywhere so I can't test exactly what it does.

Please file a bug (I'd do it but my experience is that me arguing for something to p5p makes it less likely to happen).

[ribasushi]

Right... thanks for putting this into perspective - the complexity (and the reason why it isn't implemented) becomes apparent.

By the way I was involved in making the $@ "fix" for 5.14 a little less troublesome. Here is a writeup, and here is the "fix of fix" that ended up shipping in 5.14

[tye]

Thanks for the links.

That hints that the "work to come" that ikegami alluded to is possibly the providing of a proper "we are in the middle of throwing an exception" indicator for use by Perl code.

So it seems well worth filing a bug here.

Note that the work to fix this quite well can be quite small, I believe. Perl is already putting implicit 'eval' blocks around each call to a d'tor so the nightmares of lots of C++ implementations aren't the types of problems we are fighting here.

If we simply change the spot that prepends "(in cleanup)" so that it acts "just normal" if we aren't already unrolling the stack due to a prior exception, then we are in quite good shape.

[Even better would be to also make the "(in cleanup)" exception be logged to STDERR even if warnings aren't enabled (a "mandatory warning" or what perldiag calls "severe warning"). Then you can silence such by using a __DIE__ handler.]

Accomplishing the lion's share of the fix does involve tracking "are we unrolling?", but you don't have to do all of the hard work of making this available to Perl code (picking a variable name and getting everybody to like the name). You just need a single stinkin' "global" C variable. Actually, I'd just define a new bit for EVAL_*, something like EVAL_UNWINDING.

The names G_KEEPERR and EVAL_KEEPERR suck. It would be better to name these more like G_DESTROY and EVAL_DESTROY, documenting both what they are supposed to mean and when they supposed to be used, not what behavior that meaning currently leads to.

Then the code that (in 5.14) sets ERRSV ($@) early would also set EVAL_UNWINDING. The code that prepends "in cleanup" and just warns, would only do that if EVAL_UNWINDING was also already set. If EVAL_UNWINDING was not already set, then it would set ERRSV and also set EVAL_UNWINDING.

Then a later enhancement can be done to define ${^THROWN} or whatever and change the early setting of ERRSV to instead set that new (read-only) Perl global (and instead of checking for EVAL_UNWINDING you just check for global being set and we can get rid of EVAL_UNWINDING).

[ribasushi]

Interesting. I updated the original (year old) bugreport with you comments, and forwarded them to p5p. Let's see what happens this time :)

[ikegami]

just completely ignoring during-DESTROY exceptions? I don't have 5.14 handy anywhere so I can't test exactly what it does.

They are output to STDERR like before.

$ perl -Mwarnings -Mstrict -E '
  sub DESTROY { say "invoked destructor"; die "aieeee" }
  say "creating object";
  { bless( {} ) }
  say "object destroyed (should not reach here): $@"
'
creating object
invoked destructor
        (in cleanup) aieeee at -e line 2.
object destroyed (should not reach here):

Like before, that only happens if warnings are on, so it can be completely silent!!

IIRC, more work is planned, but I haven't heard anything in a while.

[ribasushi]

Please see http://www.perlmonks.org/?node_id=945741 for an icky, but quite workable solution.

Cheers!