What happens when an exception is not caught?

[Digital Puer]

Sorry for the rudimentary question. I found the following posting
online and did not know the answer myself.


"Reminds me of a time I had a phone interview concerning a C++ job.
Didn't help that the interviewer had a very thick Slavic accent. He
asked me what happens when an exception doesn't get caught. I told him
the program would terminate. He said that's not the answer he was
looking for. I gave him a kind of detailed description of the throw
process leading to "then it gets to the top level of the program and
if there is no exception handling there, the program terminates." He
said "no, what I was looking for is that the unhandledExceptionHandler
is called" (might not have the correct name.)"


Is there a default exception handler?

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Sorry for the rudimentary question. I found the following posting
online and did not know the answer myself.


"Reminds me of a time I had a phone interview concerning a C++ job.
Didn't help that the interviewer had a very thick Slavic accent. He
asked me what happens when an exception doesn't get caught. I told him
the program would terminate. He said that's not the answer he was
looking for. I gave him a kind of detailed description of the throw
process leading to "then it gets to the top level of the program and
if there is no exception handling there, the program terminates." He
said "no, what I was looking for is that the unhandledExceptionHandler
is called" (might not have the correct name.)"


Is there a default exception handler?

Yes, the terminate() function is called, the user can specify a function
to be called by terminate(), however this function is not allowed to
return, but must terminate execution of the program. But it is allowed
to do some other stuff first.

 

[Victor Bazarov]

Sorry for the rudimentary question. I found the following posting
online and did not know the answer myself.


"Reminds me of a time I had a phone interview concerning a C++ job.
Didn't help that the interviewer had a very thick Slavic accent. He
asked me what happens when an exception doesn't get caught. I told him
the program would terminate. He said that's not the answer he was
looking for. I gave him a kind of detailed description of the throw
process leading to "then it gets to the top level of the program and
if there is no exception handling there, the program terminates." He
said "no, what I was looking for is that the unhandledExceptionHandler
is called" (might not have the correct name.)"


Is there a default exception handler?

The default "unhandled exception handler" is "std::terminate". The
Standard describes the cases in which it's called in [except.terminate]
(15.5.1 in the current edition).

V

 

[Just me]

Is there a default exception handler?

or you can make sure that any exception is caught by using


try {}
catch(exception_type_a a) {}
catch(exception_type_b b) {}
catch(exception_type_c c) {}
catch(...) {}

the (...) means catch any uncaught exception that is thrown in the try
block

otherwise, as others have mentioned, the terminate() function can provide
a graceful exit from your program.

 

[Frank Birbacher]

Hi!

Yes, the terminate() function is called, the user can specify a function
to be called by terminate(), however this function is not allowed to
return, but must terminate execution of the program. But it is allowed
to do some other stuff first.

What is the state of global variables in a terminate handler which is
installed by set_terminate? Are they destructed prior to entering the
handler?

Frank

 

[Victor Bazarov]

[..]
What is the state of global variables in a terminate handler which is
installed by set_terminate? Are they destructed prior to entering the
handler?

It's not really specified, but since the default terminate_handler is
'abort' and destructors of static objects are not called priort to
'abort' (if called by the user), they will likely not be called prior
to the call to your terminate_handler, either.

V

 

[Frank Birbacher]

Hi!

It's not really specified, but since the default terminate_handler is
'abort' and destructors of static objects are not called priort to
'abort' (if called by the user), they will likely not be called prior
to the call to your terminate_handler, either.

Does then (or should) abort() care for destruction of globals? Or is it
that the destructors are never run in this case?

Frank

 

[Victor Bazarov]

Hi!



Does then (or should) abort() care for destruction of globals? Or is
it that the destructors are never run in this case?

It's up to the implementors of the library whether 'abort' should care
for destruction of globals. As to your own 'terminate_handler', it is
up to you, but in most cases you won't be able to do anything except
[attempt] to call 'exit' instead of 'abort', but since your handler is
called in a funky state of the program, I am not sure calling 'exit'
is actually a good idea.

V

 

[Dilip]

Hi!

Does then (or should) abort() care for destruction of globals? Or is
it that the destructors are never run in this case?

It's up to the implementors of the library whether 'abort' should care
for destruction of globals. As to your own 'terminate_handler', it is
up to you, but in most cases you won't be able to do anything except
[attempt] to call 'exit' instead of 'abort', but since your handler is
called in a funky state of the program, I am not sure calling 'exit'
is actually a good idea.

Incidentally somebody posted a test case explaining this exact
situation at c.l.c++.m. See here:
http://groups.google.com/group/comp.lang.c++.moderated/msg/d174d65d0a890bae

 

[Dilip]

Hi!

Does then (or should) abort() care for destruction of globals? Or is
it that the destructors are never run in this case?

It's up to the implementors of the library whether 'abort' should care
for destruction of globals. As to your own 'terminate_handler', it is
up to you, but in most cases you won't be able to do anything except
[attempt] to call 'exit' instead of 'abort', but since your handler is
called in a funky state of the program, I am not sure calling 'exit'
is actually a good idea.

Incidentally somebody posted a test case explaining this exact
scenario at c.l.c++.m. See here:
http://groups.google.com/group/comp.lang.c++.moderated/msg/d174d65d0a890bae

 

[Alf P. Steinbach]

* Victor Bazarov:

It's up to the implementors of the library whether 'abort' should care
for destruction of globals.

Sorry, that's incorrect.

§3.6.3/4 abort() ... "terminates the program without executing
destructors for objects of automatic or static storage duration and
without calling the functions passed to atexit()."

In short, abort() does not execute destructors, nor exit-functions.

As to your own 'terminate_handler', it is
up to you, but in most cases you won't be able to do anything except
[attempt] to call 'exit' instead of 'abort', but since your handler is
called in a funky state of the program, I am not sure calling 'exit'
is actually a good idea.

Agreed.

 

[Jerry Coffin]

[ ... ]

otherwise, as others have mentioned, the terminate() function can provide
a graceful exit from your program.

....at least if you consider being dragged out by the heels after being
shot in the head a "graceful exit".