Exception specifications

Posted by: rmn on: 06/10/2009

• In: mechanisms
• 9 Comments

C++ provides a mechanism that allows any function to declare exactly which exception types it may throw, and these declerations are actually enforced in runtime. We will review exactly how this mechanism works, and why it is usually left unused.

Here’s the proper syntax for providing a list of exceptions that may be thrown during the execution of a specific function:

// may throw only type A or type B (or derived types):
void f () throw (A, B);

It is obviously possible to declare a function as nothrow, using empty parenthese:

// same as __declspec(nothrow):
void func () throw ();

When a specification is omitted, C++ assumes the function can throw anything.

As a side note, the exception specification is not considered as part of the function’s signature.

When inheriting, the derived function must not throw more than the base function: if base function could only throw x, the derived function may only throw (derived from) x or nothing. This is called covariance [ we will also demand covariance in returned values (why?) ].

Exception specificaion can not be enforced in compile time (for many good reasons), therefore it is enforced in run time. Every use of the previously defined f() is basically transformed by the compiler to something along the lines of:

try {
    f();
}
catch (const A &a) { throw; }
catch (const B &b) { throw; }
catch (...) { std::unexpected(); }

According to the standard (and as implemented above), the std::unexptected() function should be called when the exception specification is breached. It is possible to supply a user defined function to run instead of the default std::unexptected() by invoking std::set_unexpected().

If the function is defined as nothrow, the compiler assumes you know what you’re doing and is able to optimize away all of this exception handling. So if the code actually does throw something.. you’re going to be in a very bad place. Never use a nothrow specification unless you’re 100% certain that it’s indeed the correct situation and that it will remain so in the future.

Exception specifications encur runtime overhead due to the fact that they are enforced at runtime, and don’t have much added value. Well, other than extending the documentation of the interface by including possible exceptions — which is huge in my eyes, but still not worth the runtime penalty. This may be why they usually remain unsused.

However, using the empty throw() specification when appropriate is very important; In my opinion, functions that provide nothrow exception safety, such as destructors and de-allocators, must be marked as such (and allow extra compiler optimizations to take place).

Regarding the actual implementation of this feature on modern compilers, here’s what I came up with:

• On Microsoft’s Visual Studio (2008),
  The only supported exception specification is the empty one. When you attempt to use a non-empty specification, the following warning is issued: “warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)”
• On GNU G++ (4.3.3),
  Looks like the mechanism is implemented as required by the standard. When I threw a wrong expcetion (one that was’nt in the throw() specification), std::terminate() was invoked through std::unexptected(), as required. Here is what I got at runtime (though not even a warning during compilation): “terminate called after throwing an instance of ‘C'”