🚀 go-pugleaf

In article <smeyersDI7uqr.9vt@netcom.com> 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:

|>   If a derived class destructor throws an exception, do member and base
|>   class destructors still get called?  Consider this program:

|>     #include <iostream.h>

|>     class M {
|>     public:
|>       ~M() { cout << "M destructor\n"; }
|>     };

|>     class B {
|>       M m;
|>     public:
|>       ~B() { cout << "B destructor\n"; }
|>     };

|>     class D: public B {
|>       M m;
|>     public:
|>       ~D() { cout << "Starting D destructor\n";
|>              throw "Ouch!";
|>              cout << "Ending D destructor\n";
|>            }
|>     };

|>     int main()
|>     {
|>       D d;
|>       return 0;
|>     }

|>   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, in the same way that the remainder of D's
|>   destructor is not executed after the throw.  Different compilers do
|>   different things, however.  Who knows what is supposed to happen?

Supposed to, according to the standard, or supposed to, according to
what is necessary for the program to work.

I've not found any wording in the current draft which seems to cover
the fall of an exception in a destructor (but it's quite possible that
I haven't looked in the right places).  The closest I can come is in
section 15.2, paragraph 2: "An object that is partially constructed
will have destructors executed only for its fully constructed
sub-objects."  These seems to only be talking about exceptions in
constructors, however, although one could argue that a destructor
`unconstructs' the corresponding part of the object, which results in
a partially constructed object.

From necessity, the destructors *must* be called by the
implementation, because there is *no* way for the application to call
them.  In this regard, the problem is exactly the same as in the case
of an array; I have already posted why the user cannot finish cleaning
up the array.  To see why, suppose, in your example, that the
destructor of B throws the exception (and not the destructor of D).
How can the user possibly call the destructor of B::m, supposing he
catches the exception?

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