C++ Primer Plus

At this point you might wonder why the code uses a reference if the throw generates a copy. After all, the usual reason for using a reference return value is the efficiency of not having to make a copy. The answer is that references have another important property: A base-class reference can also refer to derived-class objects. Suppose you have a collection of exception types that are related by inheritance. In that case, the exception specification need only list a reference to the base type, and that would also match any derived objects thrown.

Suppose you have a class hierarchy of exceptions and you want to handle the different types separately. A base-class reference can catch all objects of a family, but a derived-class object can only catch that object and objects of classes derived from that class. A thrown object is caught by the first catch block that matches it. This suggests arranging the catch blocks in inverse order of derivation:

class bad_1 {...};

class bad_2 : public bad_1 {...};

class bad_3 : public bad 2 {...};

...

void duper()

{

    ...

    if (oh_no)

        throw bad_1();

    if (rats)

        throw bad_2();

    if (drat)

        throw bad_3();

}

...

try {

    duper();

}

catch(bad_3 &be)

{ // statements }

catch(bad_2 &be)

{ // statements }

catch(bad_1 &be)

{ // statements }

If the bad_1 & handler were first, it would catch the bad_1, bad_2, and bad_3 exceptions. With the inverse order, a bad_3 exception would be caught by the bad_3 & handler.

Tip

If you have an inheritance hierarchy of exception classes, you should arrange the order of the catch blocks so that the exception of the most-derived class (that is, the class furthest down the class hierarchy sequence) is caught first and the base-class exception is caught last.

Arranging catch blocks in the proper sequence allows you to be selective about how each type of exception is handled. But sometimes you might not know what type of exception to expect. For instance, say you write a function that calls another function, and you don’t know whether that other function throws exceptions. You can still catch the exception even if you don’t know the type. The trick to catching any exception is to use an ellipsis for the exception type:

catch (...) { // statements }  // catches any type exception

If you do know some exceptions that are thrown, you can place this catchall form at the end of the catch block sequence, a bit like the default case for a switch:

try {

    duper();

}

catch(bad_3 &be)

{ // statements }

catch(bad_2 &be)

{ // statements }

catch(bad_1 &be)

{ // statements }

catch(bad_hmean & h)

{ // statements }

catch (...)          // catch whatever is left

{ // statements }

You can set up a handler to catch an object instead of a reference. A base-class object will catch a derived class object, but the derived aspects will be stripped off. Thus, base-class versions of virtual methods will be used.

The exception Class

The main intent for C++ exceptions is to provide language-level support for designing fault-tolerant programs. That is, exceptions make it easier to incorporate error handling into a program design so you don’t have to tack on some more rigid form of error handling as an afterthought. The flexibility and relative convenience of exceptions should encourage programmers to integrate fault handling into the program design process, if appropriate. In short, exceptions are the kind of feature that, like classes, can modify your approach to programming.

Newer C++ compilers are incorporating exceptions into the language. For example, the exception header file (formerly exception.h or except.h) defines an exception class that C++ uses as a base class for other exception classes used to support the language. Your code, too, can throw an exception object or use the exception class as a base class. One virtual member function is named what(), and it returns a string, the nature of which is implementation dependent. However, because this method is virtual, you can redefine it in a class derived from exception:

#include

class bad_hmean : public std::exception

{

public:

    const char * what() { return "bad arguments to hmean()"; }

...

};

class bad_gmean : public std::exception

{

public:

    const char * what() { return "bad arguments to gmean()"; }

...

};

If you don’t want to handle these derived exceptions differently from one another, you can catch them with the same base-class handler:

try {

...

}

catch(std::exception & e)

{

    cout << e.what() << endl;

...

}

Or you could catch the different types separately.

The C++ library defines many exception types based on exception.

The stdexcept Exception Classes

The stdexcept header file defines several more exception classes. First, the file defines the logic_error and runtime_error classes, both of which derive publicly from exception:

class logic_error : public exception {

public:

explicit logic_error(const string& what_arg);

...

};

class domain_error : public logic_error {

public:

explicit domain_error(const string& what_arg);

...

};