exception question

[junw2000]

Hi,
Below is a simple code about exception.

#include <iostream>
using namespace std;

struct E {
const char* message;
E(const char* arg) : message(arg) { }
};

void my_terminate() {
cout << "Call to my_terminate" << endl;
};

struct A {
A() { cout << "In constructor of A" << endl; }
~A() {
cout << "In destructor of A" << endl;
throw E("Exception thrown in ~A()");
}
};

struct B {
B() { cout << "In constructor of B" << endl; }
~B() { cout << "In destructor of B" << endl; }
};

int main() {
set_terminate(my_terminate);

try {
cout << "In try block" << endl;
A a;
B b;
cout << "Leave try block" << endl;
throw("Exception thrown in try block of main()"); //LINE1
}
catch (const char* e) { //LINE2
cout << "Exception: " << e << endl; //LINE3
}
catch (...) {
cout << "Some exception caught in main()" << endl;
}

cout << "Resume execution of main()" << endl;
}

The output of the code is below:
In try block
In constructor of A
In constructor of B
Leave try block
In destructor of B
In destructor of A
Call to my_terminate
Abort

My question is when LINE1 throws an exception, the exception is caught
by LINE2, right?
Why LINE3 does not output anything?

The last line of the output is "Abort". Why is it from? Does the
function my_terminate() output the "Abort"?

Thanks

Jack

 

[Victor Bazarov]

Below is a simple code about exception.

#include <iostream>
using namespace std;

struct E {
const char* message;
E(const char* arg) : message(arg) { }
};

void my_terminate() {
cout << "Call to my_terminate" << endl;
};

struct A {
A() { cout << "In constructor of A" << endl; }
~A() {
cout << "In destructor of A" << endl;
throw E("Exception thrown in ~A()");
}
};

struct B {
B() { cout << "In constructor of B" << endl; }
~B() { cout << "In destructor of B" << endl; }
};

int main() {
set_terminate(my_terminate);

try {
cout << "In try block" << endl;
A a;
B b;
cout << "Leave try block" << endl;
throw("Exception thrown in try block of main()"); //LINE1
}
catch (const char* e) { //LINE2
cout << "Exception: " << e << endl; //LINE3
}
catch (...) {
cout << "Some exception caught in main()" << endl;
}

cout << "Resume execution of main()" << endl;
}

The output of the code is below:
In try block
In constructor of A
In constructor of B
Leave try block
In destructor of B
In destructor of A
Call to my_terminate
Abort

My question is when LINE1 throws an exception, the exception is caught
by LINE2, right?

No. You're throwing an exception while stack is unwinding. That causes
the 'terminate' to be called.

Why LINE3 does not output anything?

Because the control never gets there.

The last line of the output is "Abort". Why is it from? Does the
function my_terminate() output the "Abort"?

Not sure, but I think after the terminate handler 'abort' is called
regardless. In your implementation, 'abort' outputs "Abort", most
likely.

V

 

[mlimber]

Hi,
Below is a simple code about exception.

#include <iostream>
using namespace std;

struct E {
const char* message;
E(const char* arg) : message(arg) { }
};

void my_terminate() {
cout << "Call to my_terminate" << endl;
};

struct A {
A() { cout << "In constructor of A" << endl; }
~A() {
cout << "In destructor of A" << endl;
throw E("Exception thrown in ~A()");
}
};

struct B {
B() { cout << "In constructor of B" << endl; }
~B() { cout << "In destructor of B" << endl; }
};

int main() {
set_terminate(my_terminate);

try {
cout << "In try block" << endl;
A a;
B b;
cout << "Leave try block" << endl;
throw("Exception thrown in try block of main()"); //LINE1
}
catch (const char* e) { //LINE2
cout << "Exception: " << e << endl; //LINE3
}
catch (...) {
cout << "Some exception caught in main()" << endl;
}

cout << "Resume execution of main()" << endl;
}

The output of the code is below:
In try block
In constructor of A
In constructor of B
Leave try block
In destructor of B
In destructor of A
Call to my_terminate
Abort

My question is when LINE1 throws an exception, the exception is caught
by LINE2, right?
Why LINE3 does not output anything?

The last line of the output is "Abort". Why is it from? Does the
function my_terminate() output the "Abort"?

LINE2 would catch the char* exception you throw, except that before the
catch happens it must destroy all the automatic objects on the stack,
which includes A. Unfortunately, A's destructor itself throws an
exception, which is bad bad bad, and since you're already in the stack
unwinding process when that exception is thrown, you abort. That's how
the language is defined. See this FAQ, particularly the "Bang! You're
dead." part:

http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.3

The lesson here is: Don't throw exceptions in destructors.

Cheers! --M

 

[Pete Becker]

Not sure, but I think after the terminate handler 'abort' is called
regardless. In your implementation, 'abort' outputs "Abort", most
likely.

The terminate function is not supposed to return. Hence its name. <g> My
recollection is that the behavior of the program is undefined if it does
return, so the compiler's support library is being helpful by explicitly
calling abort.

 

[Pete Becker]

The lesson here is: Don't throw exceptions in destructors.

The bromide here is: Don't throw exceptions in destructors. The behavior
of the program is well defined (aside from the invalid terminate
handler) and easily understood.

 

[junw2000]

Thanks.

http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.3

I read the faq. Faq17.3 says that "For example, if someone says throw
Foo(), the stack will be unwound so all the stack frames between the
throw Foo() and the } catch (Foo e) { will get popped. This is called
stack unwinding."

But I can not understand it. When throw Foo(), the 'throw Foo()' is
located at the top of the stack, right? Where is 'catch (Foo e)' in the
stack? Are the } and { typos in the sentence above?

Whenever an exception is thrown, does stack unwinding happen?

Thanks.

Jack

 

[mlimber]

The bromide here is: Don't throw exceptions in destructors. The behavior
of the program is well defined (aside from the invalid terminate
handler) and easily understood.

Right, and I didn't say differently.

Cheers! --M

 

[mlimber]

Thanks.


I read the faq. Faq17.3 says that "For example, if someone says throw
Foo(), the stack will be unwound so all the stack frames between the
throw Foo() and the } catch (Foo e) { will get popped. This is called
stack unwinding."

But I can not understand it. When throw Foo(), the 'throw Foo()' is
located at the top of the stack, right? Where is 'catch (Foo e)' in the
stack?

Mr. Cline is describing what happens under the hood on many platforms.
There is no language requirement that a system stack even exist.
Perhaps, clearer would be this:

struct E1 {};
struct E2 {};
struct A { ~A() { throw E1(); } };

// ...
try
{
A a;
throw E2();
}
catch( const E1& e )
{
// ... never reached ...
}
catch( const E2& e )
{
// ... never reached ...
}

When MyException is thrown, a's destructor is called, but it also
throws an exception. Now, as per the language definition, you can only
handle one of these two exceptions at a time. So which one (E1 or E2?)
should the language pass on to your handlers? Since handling one means
the other is necessarily unhandled, the language just terminates the
program rather than try to decide for you.

Are the } and { typos in the sentence above?

He just means "catch( Foo e )" (or better, "catch( const Foo& e )",
which is in line with another FAQ:
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.7).

Whenever an exception is thrown, does stack unwinding happen?

It's technically implementation dependent, but commonly, yes.

Cheers! --M

 

[junw2000]

Mr. Cline is describing what happens under the hood on many platforms.
There is no language requirement that a system stack even exist.
Perhaps, clearer would be this:

struct E1 {};
struct E2 {};
struct A { ~A() { throw E1(); } };

// ...
try
{
A a;
throw E2();
}
catch( const E1& e )
{
// ... never reached ...
}
catch( const E2& e )
{
// ... never reached ...
}

When MyException is thrown, a's destructor is called, but it also
throws an exception. Now, as per the language definition, you can only
handle one of these two exceptions at a time. So which one (E1 or E2?)
should the language pass on to your handlers? Since handling one means
the other is necessarily unhandled, the language just terminates the
program rather than try to decide for you.


He just means "catch( Foo e )" (or better, "catch( const Foo& e )",
which is in line with another FAQ:
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.7).


It's technically implementation dependent, but commonly, yes.

Cheers! --M

Thanks a lot. I understand now. I make some changes to your code as
below:

struct E1 {};
struct E2 {};
struct A { ~A() { throw E1(); } }; //LINE0

// ...
try
{
A a;
//throw E2(); //LINE1
} //LINE2
catch( const E1& e )
{
// ... CAN BE reached ... //LINE3
}
catch( const E2& e )
{
// ... never reached ...
}

I comment LINE1. When LINE2 is reached, the object a will be destroyed,
since a is only valid within the try{} block. But this is NOT stack
unwinding. LINE0 will throw an exception. LINE3 can be reached. Is my
understanding correct?

Thanks.

Jack

 

[mlimber]

Thanks a lot. I understand now. I make some changes to your code as
below:

struct E1 {};
struct E2 {};
struct A { ~A() { throw E1(); } }; //LINE0

// ...
try
{
A a;
//throw E2(); //LINE1
} //LINE2
catch( const E1& e )
{
// ... CAN BE reached ... //LINE3
}
catch( const E2& e )
{
// ... never reached ...
}

I comment LINE1. When LINE2 is reached, the object a will be destroyed,
since a is only valid within the try{} block. But this is NOT stack
unwinding. LINE0 will throw an exception. LINE3 can be reached. Is my
understanding correct?

Yes. LINE3 can be and *will* be reached, but remember that destructors
still should not throw exceptions since it can lead to subtle errors
(i.e., the program not performing up to the requirements) like the one
discussed above in this thread.

Cheers! --M

 

[junw2000]

Yes. LINE3 can be and *will* be reached, but remember that destructors
still should not throw exceptions since it can lead to subtle errors
(i.e., the program not performing up to the requirements) like the one
discussed above in this thread.

Cheers! --M

I got it.
Thank you very much.

Jack