🚀 go-pugleaf

> ==========Scott Meyers, 11/10/95==========

 [snip]

>   >     T               a[ 5 ] ;
>   >
>   >When destructing the third element (for example), an exception is
>   >thrown.  Are the remaining elements destructed?  I would say yes.  

[another agreement deleted]

> I'm inclined to disagree.  How is destruction to continue?  Suppose we
> have this:
> 
>   try {
>     T a[5];
>   }
>   catch (...) {
>     // do something here
>   }
>   
> Now suppose destruction of a[3] throws.  Do we go to the handler?  If
> so, do we then go back into the try block to try destroying the rest of
> a?  What if the handler does a rethrow, and the exception is not
> caught for
> many stack frames.  After handling the exception, there is no
context to
> return to to continue destroying a.  I don't see how this can work.
> 
> If we don't go to the handler when a[3] throws, what if a[2]'s
destructor
> also throws?  Then we've got two active exceptions, and it's terminate
> time.  


Although the wisdom of continuing the backward destruction
of the array may be quite suspect, it seems that 15.2 of DWP
gives compilers no choice but to do that.  The danger seems
to be an inherent part of requiring exception handling
(including the destructor processing while unwinding) to be
exception-free.  Part of the problem here is that there can be
an environmental thing for class T (or that particular array)
that puts destruction of the other instances into the same
exception case.  If that is the case, the destructor for the
class has to do the initial catch and put the class into
a special state before rethrowing it.  Further, the exception
instance has to deal with notifying class T on its "final"
destruction.  If temporaries can get destroyed after copying
those are not "final" destructions.  The notification would
take the class out of the special state if appropriate.

If the problem is not environmental to T, then you must take
your chances, but the DWP seems to say compilers better
continue with destruction of the array.

A related question is:
Does the DWP require the frames to be unwound
while it looks for a handler that catches the exception,
so that if it does not find a valid catcher all frames
are still gracefully undone (barring another exception)?



Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]