Handling of C++ Exceptions

[ramceb]

In general C++ code shall be compiled with -fexceptions (i.e., with support for C++ exceptions). The chapter Exceptions - Doing Without of the GNU libstdc++ reference manual explains why:

Before detailing the library support for -fno-exceptions, first a passing note on the things lost when this flag is used: it will break exceptions trying to pass through code compiled with -fno-exceptions whether or not that code has any try or catch constructs. If you might have some code that throws, you shouldn't use -fno-exceptions. If you have some code that uses try or catch, you shouldn't use -fno-exceptions.

Anyhow in safety-related code, exceptions shall only be used for non-recoverable errors as the stack unwinding itself is not deterministic and not part of the qualification scope of most qualified compilers.

Therefore C++ exceptions shall be avoided.

Anyhow as some libraries e.g. the C++ STL cannot be refactored it can occur that a piece of code which is linked to a safety application throws an exception.

If safety-related code throws an exception, the program shall terminate immediately.

This is necessary to prevent the nondeterministic behavior of exception handling (e.g., unbounded worst-case execution time of destructors during stack unwinding, memory exhaustion during the allocation for the exception to be thrown).

Example implementation:
According to the Itanium C++ ABI Specification, throwing an exception looks like this:

Based on this outline, throwing an object X as in:

throw X;

will produce code approximating the template:

// Allocate -- never throws:
temp1 = __cxa_allocate_exception(sizeof(X));

// Construct the exception object:
#if COPY_ELISION
  [evaluate X into temp1]
#else
  [evaluate X into temp2]
  copy-constructor(temp1, temp2)
  // Landing Pad L1 if this throws
#endif

// Pass the exception object to unwind library:
__cxa_throw(temp1, type_info<X>, destructor<X>); // Never returns

// Landing pad for copy constructor:
L1: __cxa_free_exception(temp1) // never throws

To abort as early as possible __cxa_allocate_exception() can be overloaded as it is the first function that is called when throwing an exception.

throw std::exception{};  // calls __cxa_allocate_exception()
throw 1;  // calls __cxa_allocate_exception()
throw;  // does not(!) call __cxa_allocate_exception(), but calls std::terminate() (see https://timsong-cpp.github.io/cppwp/n4140/except#terminate-1.8)

Overload __cxa_allocate_exception() to immediately call std::abort():

///lib/safe_except/safe_except.h

extern "C" void* __cxa_allocate_exception(size_t) {
    std::abort();
}

[qor-lb]

Originally answered in #677.

The Problem

A 100% MC/DC coverage must be achieved for all parts of the code. When implementing constructs that perform bounce checks, and on failure abort the execution and transition to a safe state, this must also be tested.

The standard approach is to override the fatal error handler and replace it with an exception. However, this approach can only be used if all underlying constructs are at least weak exception-safe and the test code does not contain any undefined behavior.

Weak Exception Safety

An operation providing a weak guarantee ensures that, in the event of errors or exceptions, related objects remain in a consistent but unspecified state. What constitutes "consistency" can vary, but at a minimum, each object can be safely destroyed or reassigned.

Strong Exception Safety

An operation providing a strong guarantee ensures that, in the event of errors or exceptions, all related objects remain in the same state they were in at the beginning.

Implementation: Copy-And-Swap Idiom

To reassign a complex object with a strong exception safety guarantee, the copy-and-swap idiom is often used in C++:

1. A temporary copy is created, with exceptions potentially occurring at multiple stages.
2. If a later stage of this construction fails, the no-throw destructors of earlier stages are invoked to reclaim resources allocated to the partially constructed object.
3. Only after all possible exceptions have been handled, a no-throw swap operation updates the contents of *this.
4. The no-throw destructor of the temporary object then destroys the old contents.

If the swap operation is never reached due to an exception, the contents of *this remain unchanged.