1

This is an interview question. I told him that program may terminate if stack unwinding is already in progress.Other than that do you see any problem given that the exception is properly handled. I told him no as long it is properly handled.But he didn't look too happy with my response.

Bill Lynch
  • 80,138
  • 16
  • 128
  • 173
rahul
  • 6,447
  • 3
  • 31
  • 42
  • 1
    The expected answer is probably: "Don't do it". Read here for more: http://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor – Misch Apr 11 '13 at 14:24
  • If your class is being destructed because an exception was thrown and the stack was unwinding, and the destructor throws an exception, the program will immediately terminate. There is no way to catch or handle such an exception. – Wug Apr 11 '13 at 14:29
  • 1
    You probably should have clarified your answer relative to throwing an exception *out* of a destructor vs. *within* a destructor, when trying to establish reason for answering the way you did. – WhozCraig Apr 11 '13 at 14:34

3 Answers3

3

Well, you have no way of knowing if there's already an active exception. If there is, the program will terminate if you let another exception escape from the destructor.

Thus I don't really follow your argument:

I told him no as long it is properly handled.

How can you "properly handle" it, other than by not letting it escape from the destructor in the first place? If I were the interviewer, that would have been my next question.

NPE
  • 486,780
  • 108
  • 951
  • 1,012
0

If you are throwing from a destructor, this means that the exception is actually leaving the destructor. So the properly handled part is out of the question: you have no way of knowing how will it be handled.

There is an additional subtle problem: in many non-trivial cases, it is impossible (or, at least, very costly) to write exception-safe code unless destructors are assumed not to throw. If your destructor throws, users of your class will not be able to write good code with it. For example: it is impossible to write an exception-safe destructor for a container unless the destructors of the objects it contains are guaranteed not to throw. There will not be a call to terminate(), but the container destructor will leak resources.

Gorpik
  • 10,940
  • 4
  • 36
  • 56
0

Throwing from a destructor makes no sense.

About the only recoverable kind of error in the destructor is an I/O error while closing/flushing a file (or similar errors with the network, etc). But recovering from these conditions is trivial. Just report the error and continue. You don't need that file anyway, you have just tried to close it! It is wasteful to abandon whatever you were doing because of an error in a file you don't even need.

All other kinds of failure that may happen in a destructor, such as inability to unlock a mutex or free a block of memory, are probably not recoverable and warrant a call to terminate().

On the other hand, an error to allocate a resource, or failure to do somee I/O in the middle of a computation, warrant throwing because the computation cannot continue. But this should not happen in a destructor, or if it does, it should be handled within a destructor (why? again, it makes no sense to let it propagate away, this would not stop the error and would abandon a computation that could be happily continued).

So even if throwing from a destructor were made perfectly safe and well-defined, it would not buy us too much.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243