In article <M4mJ79Bmlt$7EwfF@robinton.ntlworld.com>, Francis Glassborow
wrote:

 > I think the rule is
 > that during stack unwinding no exception may escape the function in
 > which it is raised.

I believe there is an issue with the standard here.  Clearly, an exception
escaping from the destructor of one of the objects the must be cleaned up
during stack unwinding is a disaster, and should result in a call to
terminate().  Let's call this set of destructors 'directly-invoked',
because they're directly invoked by the stack unwinding logic.

An exception escaping from some other function called from a
directly-invoked destructor need to be a problem, as a long as it's handled
before the directly-invoked destructor returns control to the stack
unwinding logic.  In addition, it shouldn't matter whether or not that
other function itself is a destructor.

This is how I've always interpreted the standard, but after re-checking
it, I'm not so sure anymore.  Here are some quotes:

15.2.3:

   The process of calling destructors for automatic objects constructed
   on the path from a try block to a throw-expression is called stack
   unwinding. [Note: If a destructor called during stack unwinding exits
   with an exception, terminate is called (15.5.1). So destructors
   should generally catch exceptions and not let them propagate out of
   the destructor.  end note]

15.5.1:

   In the following situations exception handling must be abandoned for less
   subtle error handling techniques:

   [snip]

   when the destruction of an object during stack unwinding (15.2)
   exits using an exception

   [snip]

   In such cases, void terminate() is called.

The standard appears to be quite clear that an exception escaping from
*any* destructor called during stack unwinding causes a call to terminate
(), and does not distinguish between directly-invoked and
indirectly-invoked destructors.  However, I doubt that this is what was
really intended: as is already true for any other function called during
stack unwinding, calling terminate() should not be necessary if the second
exception is handled before it escapes from the directly-invoked destructor.

- Wil

--
Wil Evers, DOOSYS R&D, Utrecht, Holland
[Wil underscore Evers at doosys dot com]


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]