StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Simple answer, never allow an exception from a dtor! </p> <p>The complicated answer. You only get really nailed if the exception escapes the dtor while another exception is active. The normal case for this is when you are already unwinding the stack from another exception and the object in question is destroyed. In that case if the exception escapes the dtor then <code>std::terminate</code> is called, note you can put in your own handler for <code>std::terminate</code> by calling <code>std::set_terminate</code>. The default implementation of <code>std::terminate</code> is to call abort.</p> <p>To complicate things more, most functions that want to make any guarantee about their exception safety, mainly the basic guarantee or the strong guarantee, rely on the underlying types to themselves not throw in their dtor*</p> <p>The real question is, what state would your program be in when this error occurs? How can you recover? Where should this recovery be handled? You need to look at your specific case and work these issues out. Sometimes it's just fine to catch the exception and ignore it. Other times you need to raise some red flags.</p> <p><strong>So the answer is: it allowed by C++ to throw an exception in a dtor, but you shouldn't ever allow it to escape.</strong> </p> <p>*Here's a brief <a href="http://www.gotw.ca/gotw/082.htm" rel="nofollow noreferrer">synopsis</a> of the exception guarantees (here's a much longer <a href="http://www.boost.org/community/exception_safety.html" rel="nofollow noreferrer">article</a>)</p> <blockquote> <ol> <li>Recap: Briefly define the Abrahams exception safety guarantees (basic, strong, and nothrow).</li> </ol> <p>The basic guarantee is that failed operations may alter program state, but no leaks occur and affected objects/modules are still destructible and usable, in a consistent (but not necessarily predictable) state.</p> <p>The strong guarantee involves transactional commit/rollback semantics: failed operations guarantee program state is unchanged with respect to the objects operated upon. This means no side effects that affect the objects, including the validity or contents of related helper objects such as iterators pointing into containers being manipulated.</p> <p>The nothrow guarantee means that failed operations will not happen. The operation will not throw an exception.</p> </blockquote>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload