When is it OK to throw an exception from a destructor in C++?

Question

I know the rule is to NEVER throw one during a destructor, and I understand why. I would not dare do it. But even the C++ Faq Lite says that this rule is good 99% of the time. What is the other 1% that they fail to delve into?

Link to the C++ Faq Lite bullet point on throwing from ~():

Answer 1

If everything's so knackered that you want to cause the program to terminate via the exception code flow.

Answer 2

If the destruction is part of a controlled process, then it would be acceptable, but still, you need to get rid of remaining references as much as possible, so throwing might not be good.

Destruction can happen implicitely so often that a throw might break the normal code logic.

Answer 3

You would have to guarantee that the destructor is not being called, because of another exception.

That being said I don't use exceptions. But if I was compelled to use them to keep my job, I'd never throw an exception from a destructor.

Answer 4

Just don't do it. If the stars and planets align in such a way that you find you need to...

Still don't do it.

Answer 5

You can throw an exception from a destructor if this destructor is not called automatically during stack unwinding, or throwing the exception will result in a call of terminate(). To determine if it is safe to throw exceptions from a destructor, use standard function uncaught_exception(); if it returns false, it is safe to throw an exception

Answer 6

Wow, I was about to vote Juan up until I saw the part about never using exceptions.

Okay, first of all, Juan has it correct. If, for whatever reason, you end up in that situation of two exceptions chasing one another up the stack, C++ will simply throw up its hands and its last meal and terminate abnormally. So, throwing an exception from a dtor is a guarantee that you have a possible code path that leads to an unplanned abnormal termination, which is in general a bad thing. If that's what you want, be straightforward about it, call abort or exit, and get it over with.

The part about avoiding it by not using exceptions, however, is bad advice. Exceptions are really an essential mechanism in C++ for systems that are going to be robust and run for a long time; they're really the only way to guarantee that you can handle error situations without leaking resources all over the floor.

It happens I used to work for Marshall Cline, the guy who wrote that FAQ, and taught C++ from the FAQ Book; because of that, I can tell you you're misinterpreting the answer a little. He's not saying "gee, there is this one case where it would be okay, but I'm not goin to ell you about it," he's saying "I'm sure that if I say absolutely and without exception don't throw from a dtor someone, someday, will come up with one off-the-wall example that makes sense. But I don't know of one and don't really believe it. Don't try this at home, and consult an attorney, no warranty express or implied."

Answer 7

I suppose if you could reliably detect a really bad situation inside a destructor, one that was so bad that there was no good way to deal with it, and you had to ensure that the process stopped NOW before something else happened.... (imagine a computer hooked up to a gun or a nuclear missile) but two other thoughts come to mind:

1. Instead of throwing an exception it would be better to call exit() or abort() or TerminateProcess() or something that explicitly stops things, rather than assuming that you know what the compiler will turn your "throw an exception in the destructor" into when it compiles.

2. This is more of a contrived example. Extreme safety checks should be handled in a real function that's executed on purpose at well-defined times (or better yet, handled in hardware or redundant processors) and not as an afterthought during a destructor.