Thread: exception in the destructor

Which of the following reasons describe why a destructor cannot throw an exception in C++?

A. The C++ language does not permit it; a throw statement in a destructor will be caught as an error by the compiler.
B. It can invoke the terminate() handler.
C. Since the object is being destroyed, it is illogical to throw an exception then.
D. A destructor may be invoked as a result of stack unwinding while an exception is being handled.
E. A destructor in C++ cannot implement a try...catch block.

Ok,
* A is incorrect - you can throw an exception in an destructor
* B is correct - since if a destructor, called by the language runtime during stack unwinding, terminates
with an exception the whole program is terminated.
* C is correct - not sure why, but that answer makes sense to me.
* D unsure
* E is incorrect.

Can someone please confirm/comment? Thx

B. If you consider that a bad thing Well, it is...
C. That's probably somewhat subjective. It is illogical since the destruction must be completed (instance is considered dead for the rest of the program as soon as destructor is called, not when the destructor call finishes). On the other hand, why would it be illogical to want to find out if the destruction completed normally/successfully?
D. Probably most likely reason.

Also, the question should probably say shouldn't. You can throw from destructor, it is just a very bad thing to do.

It also misses some important points, e.g. you're not allowed (no diagnostic required) to put objects with throwing destructors into standard containers - or have them interact with any element of the standard library, pretty much.

Originally Posted by CornedBee

It also misses some important points, e.g. you're not allowed (no diagnostic required) to put objects with throwing destructors into standard containers - or have them interact with any element of the standard library, pretty much.

If you absolutely have to have some kind of object which could fail to be destructed, you have to bite the bullet and use two-phase cleanup and specify that the destructor cannot be called until the object has been cleaned.

You're stuck relying on programmer carefulness but I don't know a better way around the limitations.