Page History

Throwing an exception requires collaboration between the execution of the throw expression , and the passing of control to the appropriate catch statement, if any one applies. This collaboration takes the form of runtime logic used to calculate the correct handler for the exception , and is an implementation detail specific to the platform. For code compiled by a single C++ compiler, the details of how to throw and catch exceptions can be safely ignored. However, when throwing an exception across execution boundaries, care must be taken to ensure the runtime logic used is compatible between differing sides of the execution boundary.

An execution boundary is the delimitation between code compiled by differing compilers, including different versions of a compiler produced by the same vendor. For instance, a function may be declared in a header file , but defined in a library that is loaded at runtime. The execution boundary is between the call site in the executable , and the function implementation in the library. Such boundaries are also called ABI boundaries, as called ABI (application binary interface) boundaries because they relate to the interoperability of application binaries.

Page properties

hidden	true

This definition is identical to the one in EXP60-CPP. Do not pass a nonstandard-layout type object across execution boundaries, so we may want to consider adding it to the definitions section instead, perhaps.

...

Throw an exception across an execution boundary only when both sides of the execution boundary use the same ABI for exception handling.

Noncompliant Code Example

In this noncompliant code example, an exception is thrown from a library function to signal an error. Despite the exception being a scalar type (and thus , implicitly conforming to EXP60-CPP. Do not pass a nonstandard-layout type object across execution boundaries), this code can still result in abnormal program execution if the library and application adhere to different ABIs.

Code Block

bgColor	#FFCCCC
lang	cpp

// library.h
void func() noexcept(false); // Implemented by the library
 
// library.cpp
void func() noexcept(false) {
  // ...
  if (/* ... */) {
    throw 42;
  }
}
 
// application.cpp
#include "library.h"

void f() {
  try {
    func();
  } catch(int &Ee) {
    // Handle error
  }
}

Implementation Details

If the library code was is compiled (with modification to account for mangling differences) with GCC 4.9 on a default installation of MinGW-w64 without special compiler flags, the exception throw will rely on the zero-cost, table-based exception model that is based on DWARF and uses the Itanium ABI. If the application code is compiled with Microsoft Visual Studio 2013, the catch handler will be based on Structured Exception Handling and the Microsoft ABI. These two exception-handling formats are incompatible, as are the ABIs, resulting in abnormal program behavior. Specifically, the exception thrown by the library will is not be caught by the application, and std::terminate() is eventually called.

...

In this compliant solution, the error from the library function is indicated by a return value instead of an exception. Using Microsoft Visual Studio (or GCC) to compile both the library and the application would also be a compliant solution , as because the same exception-handling machinery and ABI would be used on both sides of the execution boundary.

...

The effects of throwing an exception across execution boundaries depends on the implementation details of the exception-handling mechanics, and . They can range from correct or benign behavior to undefined behavior.