🚀 go-pugleaf

In article <48m6b8$2ll@engnews1.eng.sun.com> clamage@Eng.sun.com
(Steve Clamage) writes:

|> smeyers@netcom.com (Scott Meyers) writes:

|> >I posted this a while ago as part of a larger posting, but nobody ever
|> >responded.  I'm reposting it as a separate question in hope of gaining
|> >insight into the proper behavior of destructors when exceptions are thrown:

|> >  ...

|> >  When d is destroyed, D's destructor throws.  Are destructors
|> >  nevertheless called for d.D::m, the B part of d, and d.B::m?  My feeling is
|> >  the answer should be no, ...

|> The draft says that when an exception is thrown, control is transferred
|> to the handler for that exception, or to the terminate function if
|> there is no handler.

|> I don't see how to interpret that to allow any additional processing if
|> the destructor exits via an exception.

The draft requires unwinding of the stack.  This is definitly
additional processing.

|> The special cases of operator new or a constructor exiting via an
|> exception as part of a new-expression has some additional handling,
|> but I don't see any special cases for destructors.

There are two separate issues:

In 15.2, there is no mention of operator new or constructors.  There
is a statement as to how "partially constructed objects" are handled.
This would seem relevant to Scott's question: since a destructor
"unconstructs" an object, it would seem a reasonable interpretation,
if not the most obvious, that an object whose destructor has been
called is partially constructed.  (If this is actually the desired
interpretation, then I think it would be better if it were made a
little bit more explicit.)

With regards to actually deleting the memory when the exception occurs
during a delete expression: as you say, the standard makes no special
case, and (as I have pointed out in other postings) the user has no
way of deleting it either.  In this case, the present wording of the
standard imposes a memory leak.

|> In other words, the base-class destructors should not be run. LOTS
|> of things about exceptions have needed clarification or changes
|> in the rules, so it wouldn't be surprising to see variation in
|> compiler behavior right now.

More generally, the status with regards to destructors/delete reminds
me of the status in the ARM with regards to new expressions.  It
wasn't quite clear what was intended, but the consequences of a strict
interpretation (the implementation did not free the memory) simply
made it impossible to write a program without memory leaks.  Because
of this, no reasonable implementation implemented this interpretation.

Now that the problem has been recognized in destructors/delete, I
would not expect a reasonable implementation to implement exactly what
is stated either, but rather that it call the destructors for the yet
fully constructed objects, and delete the memory.  The difference is,
of course, unlike the case when the problems with operator new were
recognized, most implementations already have exceptions, and handle
this case in various ways.

|> Apart from all of that, it is unlikely to be a good idea to throw
|> an exception from a destructor. It would be safer and less likely
|> to leave the program in an unknown state to use some other error-
|> reporting method for destructors.

I agree.

I see three possible solutions that the committee could adopt:

1. Define detailed special cases like is currently done for exceptions
in a new expression, requiring the implementation to destruct all
sub-objects, and actually call operator delete() if the exception
occurs in a delete expression.  (Why not doing this doesn't work has
been described in another posting.)

2. Declare that destructors all have an implicit "throw()"
specification, which cannot be changed by the programmer.  An
exception which propagates out of a destructor thus results in a call
to unexpected.  Alternatively, it could simply say that an exception
which propagates out of a destructor always calls terminate, rather
than this being a special case when unwinding the stack due to a
previous exception.

3. Declare that an exception which propagates out of a destructor is
undefined behavior, and leave it up to the implementations whether
they want to do anything about it or not.

Given the time constraints, I slightly favor 2, although 1 would be
quite acceptable if the committee can find time to work out all of the
details.  I would rather not see 3.

BTW: it is rather simple to avoid the consequences of an exception
propagating out of a destructor: just encapsulate the destructor in a
function try block, e.g.:

	T::~T() try
	{
	    // ...
	}
	catch (...)
	{
	}

Any exception which propagates out to the destructor is just ignored.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


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