C++, an exception in the constructor of a static object bypasses destructors of prior static objects

Question

I'm figuring out how to add C++ exception handling to deal with run-time errors in an existing real-time application. I'm starting with failures in the construction of objects that encapsulate drivers for components of the hardware system, for example a power supervisor microcontroller that sits on the SPI bus of the Raspberry Pi platform.

Following RAII principles, I must fully initialize these objects in their constructors, which leads to the possibility of failure if system resources are not available, for example if the SPI driver does not load. Since constructors don't have return values, I must deal with such failures using exceptions.

These hardware driver objects are static (file scope). Why? So that their constructors are called automatically and, more important, their destructors are called automatically on program exit. Also, I need to get to the objects from anywhere in the main program file since they represent global hardware resources.

I don't really care how the exception is handled (I can emit useful error information before the throw) but I do care that the program terminates properly.

What is happening is that if the constructor of a statically allocated object fails and throws an exception, then the destructors of other static objects that are lexically before the failing object are not called. I have tested this in a minimal test bed. Classes Apple, Pear and Orange have nothing but constructors and destructors that announce themselves to stdout, except that the constructor of Orange then throws an exception. In the main file, I define one static instance of Apple, Pear and Orange, in that order. The constructors are called on program execution, Orange throws its exception and the program ends without calling destructors for Apple and Pear.

What am I missing, here?

In the answers to similar questions, e.g. 556655, people suggest: - Not throwing exceptions in constructors. Huh? - Having a separate initialization method, called "manually" after construction, to do anything that might fail. So what about RAII? (This, by the way, is how I have things now, without exceptions). - Changing the static objects to pointers and "manually" invoking the constructors using the new operator. Then I have to manage calling the right destructors in the event of a failure, which I was hoping the use of exceptions would avoid. - Wrapping every static object inside another object which has an accessor function to get a reference to it. Apparently, the inner object's constructor will not be called until the first time that the accessor is called on the outer object, which would allow me to catch the exception and, presumably, this would result in a tidy exit. This seems like a horrible kludge.

Recall, I don't need to catch the exception, the program can terminate however it wants. This makes my question different from others that I have found. My question is, why aren't the destructors called for static objects that were successfully constructed?

Graham.

Answer 1

You're missing that the exception isn't handled. When the program terminates due to an unhandled exception, you're not guaranteed that destructors of local and static objects, are called (as I recall it's implementation defined). One solution is to put those objects in a common wrapper object, create it in a try block in main, and just make a pointer to it available for all that arbitrary access that maybe is there for the current globals.

Sketch:

class Drivers
{
friend auto main() -> int;
    // ...
};

namespace impl {
    Drivers* p_drivers;
}  // namespace impl

auto drivers() -> Drivers& { return *impl::p_drivers; }

auto main()
    -> int
{
    try
    {
        Drivers drivers;
        impl::p_drivers = &drivers;
        // ...
        return EXIT_SUCCESS;
    }
    catch( exception const& x )
    {
        log_failure( x.what() );
    }
    return EXIT_FAILURE;
}