What is exception-safe code?

Will define this as reasonable and well-defined behavior by classes and functions from the standard library when used by user-defined classes and functions that are themselves exception safe.

Please note that using exceptions in combination with templates imposes an additional requirement for exception safety. Instantiating types are required to have destructors that do no throw.

Using the layered approach from Abrahams, can classify library components as providing set levels of safety. These will be called exception guarantees, and can be divided into three categories.

Simply put, once thrown an exception object should continue in flight unless handled explicitly. In practice, this means propagating exceptions should not be swallowed in gratuitous catch(...) blocks. Instead, matching try and catch blocks should have specific catch handlers and allow un-handed exception objects to propagate. If a terminating catch(...) blocks exist then it should end with a throw to re-throw the current exception.

Why do this?

By allowing exception objects to propagate, a more flexible approach to error handling is made possible (although not required.) Instead of dealing with an error immediately, one can allow the exception to propagate up until sufficient context is available and the choice of exiting or retrying can be made in an informed manner.

Unfortunately, this tends to be more of a guideline than a strict rule as applied to the standard library. As such, the following is a list of known problem areas where exceptions are not propagated.

When the program throws an exception the runtime will obtain storage for a __cxa_exception header and the thrown object itself. Libstdc++ will try to use malloc to obtain storage, but provides an emergency buffer to be used if malloc fails, as described by the Itanium exception handling ABI.

Contrary to the ABI, the libstdc++ emergency buffer is not always 64kB, and does not always allocate 1kB chunks. The buffer is used as a pool for variable-sized allocations, so that it doesn't waste space for smaller exception objects such as std::bad_alloc. The total size of the buffer is scaled appropriately for the target. Specifically it depends on sizeof(void*), so that a 64-bit system uses a larger pool than a 32-bit system. This is done because for 32-bit systems the exception objects (and the exception header) require less space, and core counts and thread counts are typically lower as well.

By default, libstdc++ will use malloc to allocate the buffer on program startup. Configuring libstdc++ with the --enable-libstdcxx-static-eh-pool option will make it use a static buffer instead of using malloc.

The buffer size is chosen automatically, but can be overridden by configuring with --with-libstdcxx-eh-pool-obj-count=NUM, where NUM is the number of simultaneous allocations that should be supported. The size of the pool will be sufficient for NUM exceptions of 6 * sizeof(void*) bytes, plus another NUM exceptions captured in std::exception_ptr and rethrown using std::rethrow_exception. The buffer size determined by the obj-count value applies whether the buffer is reserved as static storage or is allocated dynamically. Setting obj-count to zero will disable the pool, so that no emergency buffer is present.

For a dynamic buffer, the default size can also be changed at runtime, per-process, via the GLIBCXX_TUNABLES environment variable. The GLIBCXX_TUNABLES environment variable should be a string of colon-separated name=value pairs. The following names will be recognized, with the specified semantics:

C++ is a language that strives to be as efficient as is possible in delivering features. As such, considerable care is used by both language implementer and designers to make sure unused features do not impose hidden or unexpected costs. The GNU system tries to be as flexible and as configurable as possible. So, it should come as no surprise that GNU C++ provides an optional language extension, spelled -fno-exceptions, as a way to excise the implicitly generated magic necessary to support try and catch blocks and thrown objects. (Language support for -fno-exceptions is documented in the GCC manual.)

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.

And what is to be gained, tinkering in the back alleys with a language like this? Exception handling overhead can be measured in the size of the executable binary, and varies with the capabilities of the underlying operating system and specific configuration of the C++ compiler. On recent hardware with GNU system software of the same age, the combined code and data size overhead for enabling exception handling is around 7%. Of course, if code size is of singular concern than using the appropriate optimizer setting with exception handling enabled (ie, -Os -fexceptions) may save up to twice that, and preserve error checking.

So. Hell bent, we race down the slippery track, knowing the brakes are a little soft and that the right front wheel has a tendency to wobble at speed. Go on: detail the standard library support for -fno-exceptions.

In sum, valid C++ code with exception handling is transformed into a dialect without exception handling. In detailed steps: all use of the C++ keywords try, catch, and throw in the standard library have been permanently replaced with the pre-processor controlled equivalents spelled __try, __catch, and __throw_exception_again. They are defined as follows.

#if __cpp_exceptions
# define __try      try
# define __catch(X) catch(X)
# define __throw_exception_again throw
#else
# define __try      if (true)
# define __catch(X) if (false)
# define __throw_exception_again
#endif

In addition, for most of the classes derived from class exception, there exists a corresponding function with C language linkage. An example:

#if __cpp_exceptions
  void __throw_bad_exception()
  { throw bad_exception(); }
#else
  void __throw_bad_exception()
  { abort(); }
#endif

The last language feature needing to be transformed by -fno-exceptions is treatment of exception specifications on member functions. Fortunately, the compiler deals with this by ignoring exception specifications and so no alternate source markup is needed.

By using this combination of language re-specification by the compiler, and the pre-processor tricks and the functional indirection layer for thrown exception objects by the library, libstdc++ files can be compiled with -fno-exceptions.

User code that uses C++ keywords like throw, try, and catch will produce errors even if the user code has included libstdc++ headers and is using constructs like basic_iostream. Even though the standard library has been transformed, user code may need modification. User code that attempts or expects to do error checking on standard library components compiled with exception handling disabled should be evaluated and potentially made conditional.

Some issues remain with this approach (see bugzilla entry 25191). Code paths are not equivalent, in particular catch blocks are not evaluated. Also problematic are throw expressions expecting a user-defined throw handler. Known problem areas in the standard library include using an instance of basic_istream with exceptions set to specific ios_base::iostate conditions, or cascading catch blocks that dispatch error handling or recovery efforts based on the type of exception object thrown.

Oh, and by the way: none of this hackery is at all special. (Although perhaps well-deserving of a raised eyebrow.) Support continues to evolve and may change in the future. Similar and even additional techniques are used in other C++ libraries and compilers.

C++ hackers with a bent for language and control-flow purity have been successfully consoled by grizzled C veterans lamenting the substitution of the C language keyword const with the uglified doppelganger __const.