1. Exception Specifications

An exception specification specifies that if the function throws an exception, the exception it throws will be one of the exceptions included in the specification, or it will be a type derived from one of the listed exceptions. An exception specification follows the function parameter list. An exception specification is the keyword throw followed by a (possibly empty) list of exception types enclosed in parentheses: void recoup(int) throw(runtime_error); An empty specification list says that the function does not throw any exception:void no_problem() throw(); An exception specification is part of the function’s interface. The function definition and any declarations of the function must have the same specification. If a function declaration does not specify an exception specification, the function can throw exceptions of any type.

Unfortunately, it is not possible to know at compile time whether or which exceptions a program will throw. Violations of a function’s exception specification can be detected only at run time. If a function throws an exception not listed in its specification, the library function unexpected is invoked. By default, unexpected calls terminate , which ordinarily aborts the program.

Specifying that a function will not throw any exceptions can be helpful both to users of the function and to the compiler: Knowing that a function will not throw simplifies the task of writing exception-safe code that calls that function. We can know that we need not worry about exceptions when calling it. Moreover, if the compiler knows that no exceptions will be thrown, it can perform optimizations that are suppressed for code that might throw.

2. Exception Specifications and Member Functions

class bad_alloc : public exception {
    public:
        bad_alloc() throw();
        bad_alloc(const bad_alloc &) throw();
        bad_alloc & operator=(const bad_alloc &) throw();
        virtual ~bad_alloc() throw();
        virtual const char* what() const throw();
};

Notice that the exception specification follows the const qualifier in const member function declarations.

3. Exception Specifications and Destructors

The above isbn_mismatch class defines its destructor as

class isbn_mismatch: public std::logic_error {
    public:
        virtual ~isbn_mismatch() throw() { }
};

The isbn_mismatch class inherits from logic_error , which is one of the standard exception classes. The destructors for the standard exception classes include an empty throw() specifier; they promise that they will not throw any exceptions. When we inherit from one of these classes, then our destructor must also promise not to throw any exceptions.

Our out_of_stock class had no members, and so its synthesized destructor does nothing that might throw an exception. Hence, the compiler can know that the synthesized destructor will abide by the promise not to throw.

The isbn_mismatch class has two members of class string, which means that the synthesized destructor for isbn_mismatch calls the string destructor. The C++ standard stipulates that string destructor, like any other library class destructor, will not throw an exception. However, the library destructors do not define exception specifications. In this case, we know, but the compiler doesn’t, that the string destructor won’t throw. We must define our own destructor to reinstate the promise that the destructor will not throw.

4. Exception Specifications and Virtual Functions

A virtual function in a base class may have an exception specification that differs from the exception specification of the corresponding virtual in a derived class. However, the exception specification of a derived-class virtual function must be either equally or more restrictive than the exception specification of the corresponding base-class virtual function.

class Base {
    public:
        virtual double f1(double) throw ();
        virtual int f2(int) throw (std::logic_error);
        virtual std::string f3() throw (std::logic_error, std::runtime_error);
};
class Derived : public Base {
    public:
        // error: exception specification is less restrictive than Base::f1's
        double f1(double) throw (std::underflow_error);
        // ok: same exception specification as Base::f2
        int f2(int) throw (std::logic_error);
        // ok: Derived f3 is more restrictive
        std::string f3() throw ();
}

By restricting which exceptions the derived classes will throw to those listed by the base class, we can write our code knowing what exceptions we must handle.

5. Function Pointer Exception Specifications

An exception specification is part of a function type. As such, exception specifications can be provided in the definition of a pointer to function:void (*pf)(int) throw(runtime_error); When a pointer to function with an exception specification is initialized from (or assigned to) another pointer (or to the address of a function), the exception specifications of both pointers do not have to be identical. However, the specification of the source pointer must be at least as restrictive as the specification of the destination pointer.

void recoup(int) throw(runtime_error);
// ok: recoup is as restrictive as pf1
void (*pf1)(int) throw(runtime_error) = recoup;
// ok: recoup is more restrictive than pf2
void (*pf2)(int) throw(runtime_error, logic_error) = recoup;
// error: recoup is less restrictive than pf3
void (*pf3)(int) throw() = recoup;
// ok: recoup is more restrictive than pf4
void (*pf4)(int) = recoup;