When is a C++ terminate handler the Right Thing(TM)?

Question

The C++ standard provides the std::set_terminate function which lets you specify what function std::terminate should actually call. std::terminate should only get called in dire circumstances, and sure enough the situations the standard describes for when it's called are dire (e.g. an uncaught exception). When std::terminate does get called the situation seems analagous to being out of memory -- there's not really much you can sensically do.

I've read that it can be used to make sure resources are freed -- but for the majority of resources this should be handled automatically by the OS when the process exits (e.g. file handles). Theoretically I can see a case for if say, you needed to send a server a specific message when exiting due to a crash. But the majority of the time the OS handling should be sufficient.

When is using a terminate handler the Right Thing(TM)?

Update: People interested in what can be done with custom terminate handlers might find this non-portable trick useful.

Answer 1

I think the right question would be how to avoid the calls to terminate handler, rather than when to use it.

Answer 2

This is just optimistic:

but for the majority of resources this should be handled automatically by the OS when the process exits

About the only resources that the OS handles automatically are "File Handles" and "Memory" (And this may vary across OS's). Practically all other resources (and if somebody has a list of resources that are automatically handled by OS's I would love that) need to be manually released by the OS.

Your best bet is to avoid exit using terminate() and try a controlled shut down by forcing the stack to unwind correctly. This will make sure that all destructors are called correctly and your resources are released (via destructors).

About the only thing I would do is log the problem. So that when it does happened I could go back and fix the code so that it does not happen again. I like my code to unwind the stack nicely for resource deallocation, but this is an opinion some people like abrupt halts when things go badly.

My list of when terminate is called:

In general it is called when the exception handling mechanism cannot find a handler for a thrown exception. Some specific examples are:

• An exception escapes main()
  • Note: It is implementation defined whether the stack is unwound here. Thus I always catch in main and then rethrow (if I do not explicitly handle). That way I guarantee unwinding of the stack (across all platforms) and still get the benefits of the OS exception handling mechanism.
• Two exceptions propagating simultaneously.
  • An exception escapes a desatructor while another exception is propagating.
  • The expression being thrown generates an exception
• An exception before or after main.
  • If an exception escapes the constructor/destructor of a global object.
  • If an exception escapes the destructor of a function static variable. (ie be careful with constructors/destructors of nonlocal static object)
  • An exception escapes a function registered with atexit().
• A rethrow when no exception is currently propagating.
• An unlisted exception escapes a method/function that has exception specifier list.
  • via unexpected.

Answer 3

Similar to a statement made in Martin York's answer, about the only thing I do in a custom terminate handler is log the problem so I can identify and correct the offending code. This is the only instance I find that using a custom terminate handler is the Right Thing.

---

Since it is implementation-defined whether or not the stack is unwound before std::terminate() is called, I sometimes add code to generate a backtrace in order to locate an uncaught exception¹.

^{1) This seems to work for me when using GCC on Linux platforms.}