🚀 go-pugleaf

> ==========Scott Meyers, 11/15/95==========
 
> In article <DI24xB.756@falcon.daytonoh.attgis.com> mennid
> <Dick.Menninger@daytonoh.attgis.com> writes:
> | Although the wisdom of continuing the backward destruction
> | of the array may be quite suspect, it seems that 15.2 of DWP
 
> For non-heap arrays, the DWP does seems to say that.  Is this
reasonable?

Ah, we going into the realm of what ought to be instead
of what is currently the case.  Well, let me ask the related
question of why do you see the earlier elements of the array
and significantly more dangerous (or different) to destruct
than some separate non-heap instance of the class.   
I thought a basic purpose of the exception mechanism is
to avoid the memory leaks from the stack frame variables.
But now you want to say: let some cases be leaks,
automatically (i.e., the programmer cannot avoid it).

I would say, unless the class KNOWS there is a special
situation with destroying additional instances, destruction
happens as normal.  But if the class does KNOW there
is a problem (below you ask for elaboration, it is here),
then KNOWing was a design issue for it and it has
to be prepared for its destructors to be called without
throwing further exceptions until this one is handled.
I forsee this as a possibility in design when the exception
is really a basic outside situation (possibly involving
hardware that must be reset and everything restarted)
that requires the program (which must stay up for other
reasons) to bail out of a fairly nested algorithm.  Often
the bailout gives the best form of expression of the problem.
In such a case, the initial detection throws the exception
but it must make sure there is internal info not to throw
it again until the exception is handled.  Any potential
temporary copies of the exception that get destroyed
cannot undo the knowledge if a copy still exists.

Also, if a class KNOWS, I suspect the distinction
between siblings in an array and disjoint variables
is not of importance.  But if the class does not know
(such as in a memory corruption case), then skipping
the siblings might not help (the heap threw the exception:
remember members can have heap data when the
basic instance is in a stack frame).

Have I made things clearer or muddier?  Or did I miss
the part you wanted clarified?
 
> | 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
 
> I don't understand this at all.  Can you elaborate?

(see above)
 
> | 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)?
> 
> The DWP makes it clear that stack frames need not be unwound if
> no handler
> is found, but if a handler is found, locals in intervening
> frames must have
> been destroyed by the time the handler is entered.

I was hoping you would cite the place to look (also
I was padding the message as one of the moderators
had a posting problem with old vs. new line count
though somehow it got in in spite of the mail he sent me).
But I suspected that.  I thought that it might be worth
considering always unwinding, but I guess a catchall
make that unimportant.

> 
> Scott

I hope this is helpful.

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. ]