🚀 go-pugleaf

clamage@Eng.sun.com (Steve Clamage) writes:

>smeyers@netcom.com (Scott Meyers) writes:
>
>>  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.

Yes, it does say that in 15.1, but it also says in 15.2 that 
as control passes between those two points, stack unwinding happens -
destructors get called.  Additional processing most definitely does occur!

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

It's not a special case, it is just the usual case of stack unwinding.
See 15.2:

|   15.2  Constructors and destructors                       [except.ctor]
| 
| 1 As  control  passes  from  a throw-point to a handler, destructors are
|   invoked for all automatic objects constructed since the try block  was
|   entered.

Note - it does NOT say "for all automatic *complete* objects".
Note that according to the definition in 1.6 [intro.object], a
sub-object is an object.  So it must include sub-objects.
In other words, according to the above quote from the April draft, base
class and member sub-objects that have been constructed since the try
block was entered should be destroyed.

Certainly the draft could be clearer - but it *is* only a draft.

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

Agreed.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

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