Re: Exception not unwinding the stack on g++ 4.5.1 ?
Am 27.11.2010 20:44, schrieb yabo:
Hi,
I've found a very strange behavior in g++ 4.5.1 and would like to know
if I'm missing something obvious.
Hard to say whether it is obvious, but it is specified in the standard ;-)
Given this trivial code :
--------------------
#include<iostream>
#include<stdexcept>
struct A {
A() { std::cerr<< "A::A()"<< std::endl; std::flush(std::cerr); }
~A() { std::cerr<< "A::~A()"<< std::endl; std::flush(std::cerr); }
};
Let me add that the extra flush calls are superfluous, std::endl is required to perform a flush already.
void f() {
A a;
throw std::runtime_error("toto");
}
int main() {
f();
}
--------------------
I expected to see both prints from ctor& dtor on output, though, that
is not what happens.
This is conforming behaviour. We run into 15.5.1/1 bullet 2 or equivalently 15.3/9:
"If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined (15.5.1)."
In your case, the stack is not unwound before the call of terminate.
Output:
--------------------
$ g++ -O0 -fno-inline terminate.cc&& ./a.out
A::A()
terminate called after throwing an instance of 'std::runtime_error'
what(): toto
Aborted
--------------------
At first I thought that there might be some optimizer magic involved but
even with -O0 -fno-inline the dtor is still not called.
Nope, because this does not change the specified situation.
Interestingly enough, adding a try {} catch {} block around the call to
f() solves the problem:
--------------------
#include<iostream>
#include<stdexcept>
struct A {
A() { std::cerr<< "A::A()"<< std::endl; std::flush(std::cerr); }
~A() { std::cerr<< "A::~A()"<< std::endl; std::flush(std::cerr); }
};
void f() {
A a;
throw std::runtime_error("toto");
}
int main() {
try {
f();
}
catch(...) {
throw;
}
}
This is conforming as well. In this case we have a first catch handler and now 15.2/1 applies:
"As control passes from a throw-expression to a handler, destructors are invoked for all automatic objects constructed since the try block was entered. The automatic objects are destroyed in the reverse order of the completion of their construction."
Termination happens *later* initiated by the rethrow in main without any further handler. At this point the destruction process of the automatic objects has completed.
I thought that it might be a problem with output or terminal buffering,
so I tried this:
[..]
But got the same problem:
Yes, because this variant does also not fix the actual problem.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]