🚀 go-pugleaf

bglenden@colobus.aoc.nrao.edu (Brian Glendenning) writes:

>As I understand it, an object is only considered constructed when its
>constructor has finished, so that an exception thrown from within that
>constructor will not result in that object's destructor being
>called. (Its completely constructed subobjects will be however).

Right.

>What about the destructor? Is the object considered destructed when
>the destructor is *entered*, or when it *completes*?

The object is considered "partially constructed" as soon as
the destructor is entered.  It is not completely destructed either.
If an exception is thrown in the destructor, the destructor should not
be called again, but destructors for base class sub-objects should be
called as part of stack unwinding.

--
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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

>>> struct foo : public other
>>> {
>>>     ~foo {throw("BAD?");}
>>> };

>> Since the above does not result in an infinite loop on the compilers I
>> have access to, I presume that the object is considered destructed
>> when the dtor is entered.


  Compilers do not serve as a reliable definition of anything. The draft 
C++ standard is available at  http://www.cygnus.com/misc/wp/jan96  and 
a query of it is less painful than a debugging session.   :)

A quote:

15.3.10
The  fully  constructed base classes and members of an object shall be
destroyed before entering the handler of a function-try-block  of  a
constructor or destructor for that object.


  I cannot easily find any other mention of when sub-objects are 
destroyed during a destructor throw. I presume that somewhere it states 
that they shall be destroyed, since you could always force their 
destruction by writing a function-try-block with an empty handler.

  I assume that you expected your infinite loop when a *stack* object is 
destroyed, since the block in question then becomes subject to stack 
unwinding. In fact, the object which threw is excluded from the 
unwinding. This makes sense when you consider the situation of a block 
that declares multiple local objects, and destroys them in reverse order. 
If one of them throws, destruction of the whole lot does not start over 
again.


  It is generally not advisable to write destructors that throw. This can 
lead to termination of the program when they do so during stack 
unwinding, or when their object is a global.


                               David
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Although the language doesn't mandate this, it's a good idea to obey the 
rule: never, _never_, NEVER throw an exception from within a destructor. 
If there's one operation that should be guaranteed to "work", it's 
destroying an object. Remember that destructors are automatically called 
during stack unwinding when an exception is thrown. If such a destructor 
should throw another exception, what should happen? In fact, the 
standard states that in this situation, terminate() will be called, and 
terminate() is only one notch less violent than abort().

You can, of course, use exceptions _within_ a destructor, as long as you 
handle them all. Just don't let them leak out, or you'll be hosed.

If an error might occur during destruction of an object, try to design 
in a separate termination function that can be called first. For 
instance, say you've got an object that represents an open file, and 
destroying the object is supposed to commit any buffers and close the 
file. What happens if a disk write occurs during the buffer writing?

The best approach is to design the destructor so that the error is 
swallowed, to avoid violating the above rule. If you need to see the 
error, supply a commit() member that can be called before destroying the 
object, that will detect any disk errors and leave the file object in a 
state that can be destroyed without causing any errors.

-- 

Ciao,
Paul D. DeRocco
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std.c++-request@ncar.ucar.edu 
]