Why destructor is not called on exception?

Question

I expected A::~A() to be called in this program, but it isn't:

#include <iostream>

struct A {
  ~A() { std::cout << "~A()" << std::endl; }
};

void f() {
  A a;
  throw "spam";
}

int main() { f(); }

However, if I change last line to

int main() try { f(); } catch (...) { throw; }

then A::~A() is called.

I am compiling with "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86" from Visual Studio 2005. Command line is cl /EHa my.cpp.

Is compiler right as usual? What does standard say on this matter?

Rochdale

Just for information, I reproduced this same problem with the same code in Visual C++ 2003. +1 for the question. – Athalla

Answer 1

The destructor is not being called because terminate() for the unhandled exception is called before the stack gets unwound.

The specific details of what the C++ spec says is outside of my knowledge, but a debug trace with gdb and g++ seems to bear this out.

According to the draft standard section 15.3 bullet 9:

9 If no matching handler is found in a program, the function terminate()
  (_except.terminate_)  is  called.  Whether or not the stack is unwound
  before calling terminate() is implementation-defined.

Larrisa

Upvote for referencing the official standard document. – Chiclayo

Answer 2

C++ language specification states: The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression is called “stack unwinding.” Your original code does not contain try block, that is why stack unwinding does not happen.

Zulmazulu

The selected answer mentioned terminate function which is the ultimate reason. However, I think this answer is closer to the correct answer. If one does not use try, it seems stack unwinding will no happen and that's why the destructor will not be called. My experiment seemed to suggest that the destructor is called when the correct error got caught, before the code block following catch is running. – Gladstone

Answer 3

Sorry I don't have a copy of the standard on me.
I would definitely like a definitive answer to this, so somebody with copy of the standard want to share chapter and verse on whats happening:

From my understanding terminate is only called iff:

• The exception handling mechanism cannot find a handler for a thrown exception.
  The following are more specific cases of this:
  • During stack unwinding, an exception escapes a destructor.
  • An thrown expression, an exception escapes the constructor.
  • An exception escapes the constructor/destructor of a non local static (ie global)
  • An exception escapes a function registered with atexit().
  • An exception escapes main()
• Trying to re-throw an exception when no exception is currently propagating.
• An unexpected exception escapes a function with exception specifiers (via unexpected)

Unwisdom

Answer 4

In the second example, the dtor is called when it leaves the try{} block.

In the first example, the dtor is called as the program shuts down after leaving the main() function --- by which time cout may already have been destroyed.

Gomuti

No, this is wrong. The destructor is guaranteed to be called before the program leaves main. The cout destructor is guaranteed to be called afterwards. – Felecia

… correction: the destructor of a must be called before f is left! – Felecia

Also, the program never leaves main in the first example. It is aborted via terminate with via an "unexpected exception". – Ax

@ejgottl: none of the conditions for terminating via terminate() nor unexpected() are met by this example. unexpected() would require a throw specification, and terminate() would need an exception in a dtor. – Gomuti

@ejgotti: regardless, even if terminate() were called, as it shuts down, cout WILL STOP working, which was my point. – Gomuti

@James: The destructor for all objects local to f() must be called before it leaves not matter how it leaves (return/exception). Otherwise RIAA would not work. Still working out why termiate() is called this never returns so no stack unwinding. – Unwisdom

Answer 5

I assumed too that the compiler don't generate the code relative to "a" as it's not referenced but still, it's not the right behavior as the destructor does something that have to be executed.

So, i tried in VS2008/vc9 (+SP1), Debug and Release and ~A is called after the exception is thrown, getting out of f() - that is the right behavior, if i'm right.

Now i just tried with VS2005/vc8 (+SP1) and it's the same behavior.

I used breakpoints to be sure. I just checked with the console and i have the "~A" message too. Maybe you did it wrong somewhere else?

Oblate

I created text file with first example (without try), opened "Visual Studio 2005 Command Prompt" and compiled file with cl /EHa my.cpp. Run result: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. – Rochdale

I'm not familiar with the compilation parameters in command line, but i guess that it's similar to Release mode where if there is no try/catch the code will not get farther than the throw instruction (that's what happens when i try) and the application will just "crash" (that is the wanted behavior) – Oblate

Having looked at assembly listings, i believe optimizations are off by default. So it's closer to Debug. BTW, see comment by paercebal, s/he managed to reproduce with VS2003. – Rochdale

Answer 6

This question is easy to google so I share my situation here.

Make sure yor exeption does not cross extern "C" boundary or use MSVC option /EHs (Enable C++ exeptions = Yes with Extern C functions (/EHs))

Oakum