Title: Exceptions - The Details

This is the second part of a three-part series of articles describing C++ exceptions. In this part we deal with:-

The exception handling mechanism relies on two functions, terminate() and unexpected(), for coping with errors related to the exception handling mechanism itself.

Exception specifications are a way of specifying which exceptions a function may directly or indirectly throw in the function declaration. For example:

void f() throw (NoLatteException);
void (*fp)() throw (NoCookiesException);

If a virtual function has an exception-specification, then any function that overrides the virtual function shall only allow exceptions listed, or exceptions derived from those listed. This is called the co-variant rule.

struct X { .. };
struct Y { .. };

struct B {
   virtual void f() throw( X );
   virtual void g();
}

struct C : B {
   void f() throw ( X, Y );  // error
   void g() throw ( Y );     // fine
}

A function with no exception-specification is allowed to throw any exception. A function with the empty exception specification, throw(), is not allowed to throw any exceptions.

void f() throw();     // no exceptions

If an exception is thrown that is not allowed by a function's exception-specification, then unexpected() is called.

Exception specifications are a way of specifying at the point of declaration, which exceptions may thrown by this function.

struct X { .. );
struct Y { .. };

struct Thing
{
    void a();                // 1
    void b() throw (X);      // 2
    void c() throw (X, Y);   // 3
    void d() throw();        // 4
}

A function that has no throw specification (such as on line 1), is allowed to propagate any exception.

The function on line 2 is only allowed to propagate exceptions of type X.

The function on line 3 is only allowed to propagate exceptions of type X and Y.

The function on line 4 is not allowed to propagate exceptions of any kind.

Note the careful use of the word propagate here; the functions may throw disqualified exceptions, but they are expected to catch them before they escape. So, what happens if a function throws an exception that its specification disallows? Does the program fail to compile in the first place, or get nasty.

The answer is, of course, the program gets nasty; it calls unexpected().

Exception handling is a robust method for handling (distantly) reported errors. Consider the function:

void f( int ) throw( a, b, c );
Exception specifications look very useful on the surface, and they are definitely useful as self documentation.  But let's go back to why we have exceptions in C++…

If an exception that is not on the list is thrown, the default action is to terminate the program. That doesn't sound very robust. To correctly use exceptions specifications, you must include everything that can be thrown by any called function (direct or indirect). Since the primary usefulness of exceptions is to handle reported errors which may be far down the code calling chain, this means every function between the throw and the handler must specify the exception. This is pollution!

Exception specifications are hard to maintain, and carry serious (counterproductive) side-effects if not 100% correct.

Using throw() everywhere is another mistake people often fall into. Using this doesn't prevent exceptions being thrown, it merely tells the compiler that it shouldn't. If the function does, then it's terminate() time.

And there's a further problem; exception specifications and templates don't mix.

At the JACC'99, Mike Ball of Sun Microsystems said "Every language contains a few experiments that didn't work out; finalize is one for Java." Well it looks like exception specifications could be one for C++.

The C++ standard has ratified a change to the new operator.

T *p = new T;

Previously, if the call to new above failed, a null pointer would've been returned. Under the ISO C++ Standard, an exception of type std::bad_alloc is thrown. It is possible to suppress this behaviour in favour of the old style by using the nothrow version.

T *p = new (std::nothrow) T;

A further interesting question is, if you don't have enough resources to allocate a request for memory, do you expect to have enough to be able to deal with it? Most operating systems will have slowed to be unusable long before the exception gets thrown.

In these extreme cases, exceptions give you the chance to perform a graceful shutdown even if you can't remedy the situation.

In the final article of this series I shall offer some best practice guidance for making use of C++ exceptions.