Question

In certain cases – especially when an exception escapes a destructor during stack unwinding – C++ runtime calls terminate() which must do something reasonable post-mortem and then exit the program. When a question “why so harsh” arises the answer is usually “there’s nothing more reasonable to do in such error situations”. That sounds reasonable if the whole program is in C++.

Now what if the C++ code is in a library and the program that uses the library is not in C++? This happens quite often – for example I might have a native C++ COM component consumed by a .NET program. Once terminate() is called inside the component code the .NET program suddenly ends abnormally. The program author will first of all think “I don’t care of C++, why the hell is this library make my program exit?”

How do I handle the latter scenario when developing libraries in C++? Is it reasonable that terminate() unexpectedly ends the program? Is there a better way to handle such situations?

Answer 1

Why is the C++ runtime calling terminate()? It doesn’t do it at random, or due to circumstances which cannot be defined and/or avoided when the code is written. It does it because your code does something that is defined to result in a call to terminate(), such as throwing an exception from a destructor during stack unwinding.

There is a list in the C++ standard of all the situations which are defined to result in call to terminate(). If you don’t want terminate() to be called, don’t do any of those things in your code. The same applies to unexpected(), abort(), and so on.

I don’t think this is any different really from the fact that you have to avoid undefined behavior, or in general avoid writing code which is wrong. You also have to avoid behavior which is defined but undesirable.

Perhaps you have a particular example where it is difficult to avoid a call to terminate(), but throwing an exception from a destructor during stack unwinding isn’t it. Just don’t throw exceptions out of destructors, ever. This means designing your destructors such that if they do something which might fail, the destructor catches the exception and your code continues in a defined state.

There are some situations where your system will impolitely hack your process away at the knees because of something that your C++ code does (although not by calling terminate()). For example, if the system is overcommitting memory and the VMM can’t honour the promises malloc/new have made, then your process might be killed. But that’s a system feature, and probably applies equally to the other language that’s calling your C++. I don’t think there’s anything you can (or need to) do about it, as long as your caller is aware that your library might allocate memory. In that circumstance it’s not your code’s fault the process died, it’s the defined response of the operating system to low-memory conditions.