Chapter 10: Handling Errors

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Chapter 10

Handling Errors

WHAT’S IN THIS CHAPTER?

How to handle errors in C++, including pros and cons of exceptions
The syntax of exceptions
Exception class hierarchies and polymorphism
Stack unwinding and cleanup
Common error-handling situations

Inevitably, your C++ programs will encounter errors. The program might be unable to open a file, the network connection might go down, or the user might enter an incorrect value, to name a few possibilities. The C++ language provides a feature called exceptions to handle these exceptional but not unexpected situations.

The code examples in this book so far have virtually always ignored error conditions for brevity. This chapter rectifies that simplification by teaching you how to incorporate error handling into your programs from their beginnings. It focuses on C++ exceptions, including the details of their syntax, and describes how to employ them effectively to create well-designed error-handling programs.

ERRORS AND EXCEPTIONS

No program exists in isolation; they all depend on external facilities such as interfaces with the operating system, networks and file systems, external code such as third-party libraries, and user input. Each of these areas can introduce situations which require responding to problems which may be encountered. These potential problems can be referred to with the general term exceptional situations. Even perfectly written programs encounter errors and exceptional situations. Thus, anyone who writes a computer program must include error-handling capabilities. Some languages, such as C, do not include many specific language facilities for error handling. Programmers using these languages generally rely on return values from functions and other ad hoc approaches. Other languages, such as Java, enforce the use of a language feature called exceptions as an error-handling mechanism. C++ lies between these extremes. It provides language support for exceptions, but does not require their use. However, you can’t ignore exceptions entirely in C++ because a few basic facilities, such as memory allocation routines, use them.

What Are Exceptions, Anyway?

Exceptions are a mechanism for a piece of code to notify another piece of code of an “exceptional” situation or error condition without progressing through the normal code paths. The code that encounters the error throws the exception, and the code that handles the exception catches it. Exceptions do not follow the fundamental rule of step-by-step execution to which you are accustomed. When a piece of code throws an exception, the program control immediately stops executing code step by step and transitions to the exception handler, which could be anywhere from the next line in the same function to several function calls up the stack. If you like sports analogies, you can think of the code that throws an exception as an outfielder throwing a baseball back to the infield, where the nearest infielder (closest exception handler) catches it. Figure 10-1 shows a hypothetical stack of three function calls. Function A() has the exception handler. It calls function B(), which calls function C(), which throws the exception.

FIGURE 10-1

Figure 10-2 shows the handler catching the exception. The stack frames for C() and B() have been removed, leaving only A().

FIGURE 10-2

Some people who have used C++ for years are surprised to learn that C++ supports exceptions. Programmers tend to associate exceptions with languages like Java, in which they are much more visible. However, C++ has full-fledged support for exceptions.

Why Exceptions in C++ Are a Good Thing

As mentioned earlier, run-time errors in programs are inevitable. Despite that fact, error handling in most C and C++ programs is messy and ad hoc. The de facto C error-handling standard, which was carried over into many C++ programs, uses integer function return codes and the errno macro to signify errors. Each thread has its own errno value. errno acts as a thread-global integer variable that functions can use to communicate errors back to calling functions.

Unfortunately, the integer return codes and errno are used inconsistently. Some functions might choose to return 0 for success and −1 for an error. If they return −1, they also set errno to an error code. Other functions return 0 for success and nonzero for an error, with the actual return value specifying the error code. These functions do not use errno. Still others return 0 for failure instead of for success, presumably because 0 always evaluates to false in C and C++.

These inconsistencies can cause problems because programmers encountering a new function often assume that its return codes are the same as other similar functions. That is not always true. On Solaris 9, there are two different libraries of synchronization objects: the POSIX version and the Solaris version. The function to initialize a semaphore in the POSIX version is called sem_init(), and the function to initialize a semaphore in the Solaris version is called sema_init(). As if that weren’t confusing enough, the two functions handle error codes differently! sem_init() returns –1 and sets errno on error, while sema_init() returns the error code directly as a positive integer, and does not set errno.

Another problem is that the return type of functions in C++ can only be of one type, so if you need to return both an error and a value, you must find an alternative mechanism. One solution is to return a std::pair or std::tuple, an object that you can use to store two or more types. They are discussed in later STL chapters. Another choice is to define your own struct or class that contains several values, and return an instance of that struct or class from your function. Yet another option is to return the value or error through a reference parameter or to make the error code one possible value of the return type, such as a nullptr pointer. In all these solutions, the caller is responsible to explicitly check for any errors returned from the function and if it doesn’t handle the error itself, it should propagate the error to its caller. Unfortunately, this will often result in the loss of critical details about the error.

C programmers may be familiar with a mechanism known as setjmp()/longjmp(). This mechanism cannot be used correctly in C++, because it bypasses scoped destructors on the stack. You should avoid it at all cost, even in C programs; therefor this book will not explain the details of how to use it.

Exceptions provide an easier, more consistent, and safer mechanism for error handling. There are several specific advantages of exceptions over the ad hoc approaches in C and C++.

When return codes are used as an error reporting mechanism, a defect is that a caller may choose to ignore the return codes, or process them only locally without propagating them upwards, even though higher-level callers need to know there was a lower-level failure. Exceptions cannot be ignored: If your program fails to catch an exception, it will terminate.
When integer return codes are used, they generally do not contain sufficient information. You can use exceptions to pass as much information as you want from the code that finds the error to the code that handles it. Exceptions can also be used to communicate information other than errors, though many programmers consider that an abuse of the exception mechanism.
Exception handling can skip levels of the call stack. That is, a function can handle an error that occurred several function calls down the stack, without error-handling code in the intermediate functions. Return codes require each level of the call stack to clean up explicitly after the previous level.

Why Exceptions in C++ Are a Bad Thing

In some compilers (fewer and fewer these days), exception handling added a tiny amount of overhead to any function that had an exception handler. In modern compilers, this overhead is so small or even non-existing, so that you can ignore it. Do not assume that the urban legend about exceptions introducing serious overhead is true; you have to check it out in your compiler.

Exception handling is not enforced in C++. For example, in Java a function that does not specify a list of possible exceptions that it can throw is not allowed to throw any exceptions. In C++, it is just the opposite: a function that does not specify a list of exceptions can throw any exception it wants! Additionally, the exception list is not enforced at compile time in C++, meaning that the exception list of a function can be violated at run time. Note that some tools, such as using /Analyze with Microsoft VC++, will check exceptions and report potential problems.

Our Recommendation

We recommend exceptions as a useful mechanism for error handling. We feel that the structure and error-handling formalization that exceptions provide outweigh the less desirable aspects. Thus, the remainder of this chapter focuses on exceptions. Also, many popular libraries, such as the STL and Boost use exceptions, so you need to be prepared to handle them. We recommend you read the rest of this chapter, because you should not be surprised by the experience of having an exception thrown.

EXCEPTION MECHANICS

Exceptional situations arise frequently in file input and output. The following is a function to open a file, read a list of integers from the file, and store the integers in the supplied std::vector data structure. A vector is a dynamic array. You can add elements to it by using the push_back() method, and access them with array notation.

void readIntegerFile(const string& fileName, vector<int>& dest)
{
    ifstream istr;
    int temp;
    istr.open(fileName.c_str());
    // Read the integers one by one and add them to the vector.
    while (istr >> temp) {
        dest.push_back(temp);
    }
}

Code snippet from ReadIntegerFileNoExceptionHandling.cpp

The following line keeps reading values from the ifstream until the end of the file is reached or until an error occurs.

while (istr >> temp) {

This works because the >> operator returns a reference to the ifstream object itself. Additionally, ifstream provides a bool() conversion operator implemented as follows:

return !fail();

If the >> operator encounters an error, it will set the fail bit of the ifstream object. In that case, the bool() conversion operator will return false and the while loop will terminate. Streams are discussed in more detail in Chapter 15.

You might use readIntegerFile() like this:

vector<int> myInts;
const string fileName = "IntegerFile.txt";
readIntegerFile(fileName, myInts);
for (size_t i = 0; i < myInts.size(); i++) {
    cout << myInts[i] << " ";
}
cout << endl;

Code snippet from ReadIntegerFileNoExceptionHandling.cpp

The lack of error handling in these functions should jump out at you. The rest of this section shows you how to add error handling with exceptions.

Throwing and Catching Exceptions

Using exceptions consists of providing two parts in your program: a try/catch construct, to handle an exception, and a throw statement, that throws an exception. Both must be present in some form to make exceptions work. However, in many cases, the throw happens deep inside some library (including the C++ run time) and the programmer never sees it, but still has to react to it using a try/catch construct.

The try/catch construct looks as follows:

try {
    // ... code which may result in an exception being thrown
} catch (exception-type1 exception-name) {
    // ... code which responds to the exception of type 1
} catch (exception-type2 exception-name) {
    // ... code which responds to the exception of type 2
}
// ... remaining code

The code which may result in an exception being thrown might contain a throw directly, or might be calling a function which either directly throws an exception or calls, by some unknown number of layers of calls, a function which throws an exception.

If no exception is thrown, the code in the catch blocks is not executed, and the “remaining code” which follows will follow the last statement executed in the try block.

If an exception is thrown, any code following the throw or following the call which resulted in the throw, is not executed, but control immediately goes to the right catch block depending on the type of the exception that is thrown.

If the catch block does not do a control transfer, for example by returning a value, throwing a new exception or rethrowing the exception, then the “remaining code” is executed after the last statement of that catch block.

The simplest example to demonstrate exception handling is avoiding divide-by-zero. This example throws an exception of type invalid_argument which requires the <stdexcept> header.

int SafeDivide(int num, int den)
{
    if (den == 0)
        throw invalid_argument("Divide by zero");
    return num / den;
}
int main()
{
    try {
        cout << SafeDivide(5, 2) << endl;
        cout << SafeDivide(10, 0) << endl;
        cout << SafeDivide(3, 3) << endl;
    } catch (const invalid_argument& e) {
        cout << "Caught exception: " << e.what() << endl;
    }
    return 0;
}

Code snippet from SafeDivideSafeDivide.cpp

The output is as follows:

2
Caught exception: Divide by zero

throw is a keyword in C++, and is the only way to throw an exception. The invalid_argument() part of the throw line means that you are constructing a new object of type invalid_argument to throw.

The throw keyword can also be used to rethrow the current exception. For example:

void g() { throw 2; }
void f()
{
    try {
        g();
    } catch (int i) {
        cout << "caught in f: " << i << endl;
        throw;  // rethrow
    }
}
int main()
{
    try {
        f();
    } catch (int i) {
        cout << "caught in main: " << i << endl;
    }
    return 0;
}

Code snippet from Rethrow ethrow.cpp

This example produces the following output:

caught in f: 2
caught in main: 2

Let’s go back to the readIntegerFile() function. The most likely problem to occur is for the file open to fail. That’s a perfect situation for throwing an exception. This code throws an exception of type exception which requires the <exception> header. The syntax looks like this:

#include <exception>
void readIntegerFile(const string& fileName, vector<int>& dest)
{
    ifstream istr;
    int temp;
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        throw exception();
    }
    // Read the integers one by one and add them to the vector.
    while (istr >> temp) {
        dest.push_back(temp);
    }
}

Code snippet from ReadIntegerFileBasicExceptions.cpp

If the function fails to open the file and executes the throw exception(); line, the rest of the function is skipped, and control transitions to the nearest exception handler.

Throwing exceptions in your code is most useful when you also write code that handles them. Exception handling is a way to “try” a block of code, with another block of code designated to react to any problems that might occur. In the following main() function the catch statement reacts to any exception of type exception that was thrown within the try block by printing an error message. If the try block finishes without throwing an exception, the catch block is skipped. You can think of try/catch blocks as glorified if statements. If an exception is thrown in the try block, execute the catch block. Otherwise, skip it.

int main()
{
    vector<int> myInts;
    const string fileName = "IntegerFile.txt";
    try {
        readIntegerFile(fileName, myInts);
    } catch (const exception& e) {
        cerr << "Unable to open file " << fileName << endl;
        return 1;
    }
    for (size_t i = 0; i < myInts.size(); i++) { 
        cout << myInts[i] << " ";
    }
    cout << endl;
    return 0;
}

Code snippet from ReadIntegerFileBasicExceptions.cpp

Although by default, streams do not throw exceptions, you can tell the streams to throw exceptions for error conditions by calling their exceptions( ) method. However, Bjarne Stroustrup, creator of C++, likes to deal with the stream state directly instead of using exceptions (The C++ Programming Language, third edition). This book follows his style in that regard.

Exception Types

You can throw an exception of any type. The preceding example throws an object of type exception, but exceptions do not need to be objects. You could throw a simple int like this:

void readIntegerFile(const string& fileName, vector<int>& dest)
{
    // Code omitted
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        throw 5;
    }
    // Code omitted
}

Code snippet from ReadIntegerFileThrowInt.cpp

You would then need to change the catch statement as well:

try {
    readIntegerFile(fileName, myInts);
} catch (int e) {
    cerr << "Unable to open file " << fileName << endl;
    return 1;
}

Code snippet from ReadIntegerFileThrowInt.cpp

Alternatively, you could throw a char* C-style string. This technique is sometimes useful because the string can contain information about the exception.

void readIntegerFile(const string& fileName, vector<int>& dest)
{
    // Code omitted
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        throw "Unable to open file";
    }
    // Code omitted
}

Code snippet from ReadIntegerFileThrowCharStar.cpp

When you catch the char* exception, you can print the result:

try {
    readIntegerFile(fileName, myInts);
} catch (const char* e) {
    cerr << e << endl;
    return 1;
}

Code snippet from ReadIntegerFileThrowCharStar.cpp

In modern programming, you should avoid using 8-bit char* C-style strings. You should use Unicode strings which are discussed in detail in Chapter 14.

Despite the previous examples, you should generally throw objects as exceptions for two reasons:

Objects convey information by their class name.
Objects can store information, including strings that describe the exceptions.

The C++ standard library defines a number of predefined exception classes and you can write your own exception classes. Details are described later in this chapter.

Catching Exception Objects by const and Reference

In the preceding example in which readIntegerFile() throws an object of type exception, the catch line looks like this:

} catch (const exception& e) {

However, there is no requirement to catch objects by const reference. You could catch the object by value like this:

} catch (exception e) {

Code snippet from ReadIntegerFileCatchByValue.cpp

Alternatively, you could catch the object by reference (without the const):

} catch (exception& e) {

Code snippet from ReadIntegerFileCatchByNonConstReference.cpp

Also, as you saw in the char* example, you can catch pointers to exceptions, as long as pointers to exceptions are thrown.

It is recommended to catch exceptions by const reference.

Throwing and Catching Multiple Exceptions

Failure to open the file is not the only problem readIntegerFile() could encounter. Reading the data from the file can cause an error if it is formatted incorrectly. Here is an implementation of readIntegerFile() that throws an exception if it cannot either open the file or read the data correctly:

void readIntegerFile(const string& fileName, vector<int>& dest)
{
    ifstream istr;
    int temp;
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        throw exception();
    }
    // Read the integers one by one and add them to the vector.
    while (istr >> temp) {
        dest.push_back(temp);
    }
    if (istr.eof()) {
        // We reached the end-of-file.
        istr.close();
    } else {
        // Some other error. Throw an exception.
        istr.close();
        throw exception();
    }
}

Code snippet from ReadIntegerFileThrowingMultipleBasic.cpp

Your code in main() does not need to change because it already catches an exception of type exception. However, that exception could now be thrown in two different situations, so you should modify the error message accordingly:

try {
    readIntegerFile(fileName, myInts);
} catch (const exception& e) {
    cerr << "Unable either to open or to read " << fileName << endl;
    return 1;
}

Code snippet from ReadIntegerFileThrowingMultipleBasic.cpp

Alternatively, you could throw two different types of exceptions from readIntegerFile(), so that the caller can tell which error occurred. Here is an implementation of readIntegerFile() that throws an exception object of class invalid_argument if the file cannot be opened and an object of class runtime_error if the integers cannot be read. Both invalid_argument and runtime_error are classes defined in the header file <stdexcept> as part of the C++ Standard Library.

#include <stdexcept>
void readIntegerFile(const string& fileName, vector<int>& dest)
{
    ifstream istr;
    int temp;
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        throw invalid_argument("");
    }
    // Read the integers one by one and add them to the vector.
    while (istr >> temp) {
        dest.push_back(temp);
    }
    if (istr.eof()) {
        // We reached the end-of-file.
        istr.close();
    } else {
        // Some other error. Throw an exception.
        istr.close();
        throw runtime_error("");
    }
}

Code snippet from ReadIntegerFileThrowingTwoTypes.cpp

There are no public default constructors for invalid_argument and runtime_error, only string constructors.

Now main() can catch both invalid_argument and runtime_error with two catch statements:

try {
    readIntegerFile(fileName, myInts);
} catch (const invalid_argument& e) {
    cerr << "Unable to open file " << fileName << endl;
    return 1;
} catch (const runtime_error& e) {
    cerr << "Error reading file " << fileName << endl;
    return 1;
}

Code snippet from ReadIntegerFileThrowingTwoTypes.cpp

If an exception is thrown inside the try block, the compiler will match the type of the exception to the proper catch handler. So, if readIntegerFile() is unable to open the file and throws an invalid_argument object, it will be caught by the first catch statement. If readIntegerFile() is unable to read the file properly and throws a runtime_error, then the second catch statement will catch the exception.

Matching and const

The const-ness specified in the type of the exception you want to catch makes no difference for matching purposes. That is, this line matches any exception of type runtime_error.

} catch (const runtime_error& e) {

The following line also matches any exception of type runtime_error:

} catch (runtime_error& e) {

Matching Any Exception

You can write a catch line that matches any possible exception with the special syntax shown in the following example:

try {
    readIntegerFile(fileName, myInts);
} catch (...) {
    cerr << "Error reading or opening file " << fileName << endl;
    return 1;
}

Code snippet from ReadIntegerFileMatchingAnyException.cpp

The three dots are not a typo. They are a wildcard that match any exception type. When you are calling poorly documented code, this technique can be useful to ensure that you catch all possible exceptions. However, in situations where you have complete information about the set of thrown exceptions, this technique is considered suboptimal because it handles every exception type identically. It’s better to match exception types explicitly and take appropriate, targeted action.

A possible use of a catch block matching any exception is as a default catch handler. When an exception is thrown, a catch handler is looked up in the order that they appear in the code. The following example shows how you can write catch handlers that explicitly handle invalid_argument and runtime_error exceptions and how to include a default catch handler for all other exceptions.

try {
    // Code that can throw exceptions
} catch (const invalid_argument& e) {
    // Handle invalid_argument exception
} catch (const runtime_error& e) {
    // Handle runtime_error exception
} catch (...) {
    // Handle all other exceptions
}

Uncaught Exceptions

If your program throws an exception that is not caught anywhere, the program will terminate. Basically there is a try/catch construct around the call to your main() function which catches all unhandled exceptions, something as follows:

try {
    main(argc, argv);
} catch (...) {
    // issue error message and terminate program
}

However, this behavior is not usually what you want. The point of exceptions is to give your program a chance to handle and correct undesirable or unexpected situations.

Catch and handle all possible exceptions thrown in your programs.

Even if you can’t handle a particular exception, you should still write code to catch it and print or show an appropriate error message.

It is also possible to change the behavior of your program if there is an uncaught exception. When the program encounters an uncaught exception, it calls the built-in terminate() function, which calls abort() from <cstdlib> to kill the program. You can set your own terminate_handler by calling set_terminate() with a pointer to a callback function that takes no arguments and returns no value. terminate(), set_terminate(), and terminate_handler are all declared in the <exception> header. The following code shows a high-level overview of how it works.

try {
    main(argc, argv);
} catch (...) {
    if (terminate_handler != nullptr) {
        terminate_handler();
        abort();
    } else {
        terminate();
    }
}
// normal termination code

Before you get too excited about this feature, you should know that your callback function must still terminate the program, or else abort() will be called anyway. It can’t just ignore the error. However, you can use it to print a helpful error message before exiting. Here is an example of a main() function that doesn’t catch the exceptions thrown by readIntegerFile(). Instead, it sets the terminate_handler to a callback that prints an error message before exiting:

void myTerminate()
{
    cout << "Uncaught exception!" << endl;
    exit(1);
}
int main()
{
    vector<int> myInts;
    const string fileName = "IntegerFile.txt";
    set_terminate(myTerminate);
    readIntegerFile(fileName, myInts);
    for (size_t i = 0; i < myInts.size(); i++) {
        cout << myInts[i] << " ";
    }
    cout << endl;
    return 0;
}

Code snippet from ReadIntegerFileTerminateHandler.cpp

Although not shown in this example, set_terminate() returns the old terminate_handler when it sets the new one. The terminate_handler applies program-wide, so it’s considered good style to reset the old terminate_handler when you have completed the code that needed the new terminate_handler. In this case, the entire program needs the new terminate_handler, so there’s no point in resetting it.

Although it’s important to know about set_terminate(), it’s not a very effective exception-handling approach. We recommend trying to catch and handle each exception individually in order to provide more precise error handling.

Throw Lists

C++ allows you to specify the exceptions a function or method intends to throw. This specification is called the throw list or the exception specification. Here is the readIntegerFile() function from the earlier example with the proper throw list:

void readIntegerFile(const string& fileName, vector<int>& dest)
    throw(invalid_argument, runtime_error)
{
    // Remainder of the function is the same as before
}

Code snippet from ReadIntegerFileThrowList.cpp

The throw list shows the types of exceptions that can be thrown from the function. Note that the throw list must also be provided for the function prototype:

void readIntegerFile(const string& fileName, vector<int>& dest)
    throw(invalid_argument, runtime_error);

Code snippet from ReadIntegerFileThrowList.cpp

You cannot overload a function based solely on different exceptions in the throw list.

If a function or method specifies no throw list, it can throw any exception. You’ve already seen this behavior in the previous implementation of the readIntegerFile() function. If you want to specify that a function or method throws no exceptions, you need to use noexcept like this:

void readIntegerFile(const string& fileName, vector<int>& dest) noexcept;

Code snippet from ReadIntegerFile oexcept.cpp

The noexcept keyword is introduced with C++11. If your compiler is not yet C++11 compliant, you should replace the noexcept keyword with throw(). However, it is important to remember that C++11 has deprecated the empty throw() list, which means that it might disappear in future compilers.

If this behavior seems backward to you, you’re not alone. However, it’s best just to accept it and move on.

A function without a throw list can throw exceptions of any type. A function with noexcept or an empty throw list shouldn’t throw any exception.

Unexpected Exceptions

Unfortunately, the throw list is not enforced at compile time in C++. Code that calls readIntegerFile() does not need to catch the exceptions listed in the throw list. This behavior is different from that in other languages, such as Java, which requires a function or method to catch exceptions or declare them in their own function or method throw lists.

Additionally, you could implement readIntegerFile() like this:

void readIntegerFile(const string& fileName, vector<int>& dest)
    throw(invalid_argument, runtime_error)
{
    throw 5;
}

Code snippet from ReadIntegerFileUnexpectedExceptions.cpp

Even though the throw list states that readIntegerFile() doesn’t throw an int, this code, which obviously throws an int, compiles and runs. However, it won’t do what you want. Suppose that you write this main() function which has a catch block for int:

int main()
{
    vector<int> myInts;
    const string fileName = "IntegerFile.txt";
    try {
        readIntegerFile(fileName, myInts);
    } catch (int x) {
        cerr << "Caught int" << endl;
    }
    return 0;
}

Code snippet from ReadIntegerFileUnexpectedExceptions.cpp

When this program runs and readIntegerFile() throws the int exception, the program terminates. It does not allow main() to catch the int.

Throw lists don’t prevent functions from throwing unlisted exception types, but they prevent the exception from leaving the function, resulting in a run-time error.

All versions of Microsoft Visual C++, up to version 2010 at the time of this writing, do not yet support throw lists for functions as explained earlier. As a result, the preceding main() function will catch the int exception because Visual C++ just ignores the throw(invalid_argument, runtime_error) specification and will issue a warning like “warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)”. Maybe future versions will support this.

You can change this behavior. When a function throws an exception that is not listed in its throw list, C++ calls a special function unexpected(). The built-in implementation of unexpected()calls terminate(). However, just as you can set your own terminate_handler, you can set your own unexpected_handler. Unlike in the terminate_handler, you can actually do something other than just terminate the program in the unexpected_handler. Your version of the function must either throw a new exception or terminate the program — it can’t just exit the function normally. If it throws a new exception, that exception will be substituted for the unexpected exception as if the new one had been thrown originally. If this substituted exception is also not listed in the throw list, the program will do one of two things. If the throw list for the function specifies bad_exception, then bad_exception will be thrown. Otherwise, the program will terminate. Custom implementations of unexpected() are normally used to convert unexpected exceptions into expected exceptions. For example, you could write a version of unexpected() like this:

void myUnexpected()
{
    cerr << "Unexpected exception!" << endl;
    throw runtime_error("");
}

Code snippet from ReadIntegerFileUnexpectedExceptions.cpp

This code converts an unexpected exception to a runtime_error exception, which the function readIntegerFile() has in its throw list.

You could set this unexpected exception handler in main() with the set_unexpected() function. Like set_terminate(), set_unexpected() returns the current handler. The unexpected() function applies program-wide, not just to this function, so you should reset the handler when you are done with the code that needed your special handler:

int main()
{
    vector<int> myInts;
    const string fileName = "IntegerFile.txt";
    unexpected_handler old_handler = set_unexpected(myUnexpected);
    try {
        readIntegerFile(fileName, myInts);
    } catch (const invalid_argument& e) {
        cerr << "Unable to open file " << fileName << endl;
        return 1;
    } catch (const runtime_error& e) {
        cerr << "Error reading file " << fileName << endl;
        return 1;
    } catch (int x) {
        cerr << "Caught int" << endl;
    }
    set_unexpected(old_handler);
    // Remainder of function omitted
}

Code snippet from ReadIntegerFileUnexpectedExceptions.cpp

Now main() handles any exception thrown from readIntegerFile() by converting it to a runtime_error. However, as with set_terminate(), we recommend using this capability judiciously.

unexpected(), set_unexpected(), and bad_exception are all declared in the <exception> header file.

Changing the Throw List in Overridden Methods

When you override a virtual method in a subclass, you can change the throw list as long as you make it more restrictive than the throw list in the superclass. The following changes qualify as more restrictive:

Removing exceptions from the list
Adding subclasses of exceptions that appear in the superclass throw list
Making it a noexcept method

The following changes do not qualify as more restrictive:

Adding exceptions to the list that are not subclasses of exceptions in the superclass throw list
Removing the throw list entirely

If you change throw lists when you override methods, remember that any code that called the superclass version of the method must be able to call the subclass version. Thus, you can’t add exceptions.

For example, suppose that you have the following superclass:

class Base
{
    public:
        virtual void func() throw(exception) { cout << "Base!
"; }
};

Code snippet from ThrowListsVirtualMethodsCorrectOne.cpp

You could write a subclass that overrides func() and specifies that it doesn’t throw any exceptions:

class Derived : public Base
{
    public:
        virtual void func() noexcept { cout << "Derived!
"; }
};

Code snippet from ThrowListsVirtualMethodsCorrectOne.cpp

You could also override func() such that it throws a runtime_error as well as an exception, because runtime_error is a subclass of exception.

class Derived : public Base
{
    public:
        virtual void func() throw(exception, runtime_error)
            { cout << "Derived!
"; }
};

Code snippet from ThrowListsVirtualMethodsCorrectTwo.cpp

However, you cannot remove the throw list entirely, because that means func() could throw any exception.

As a second example, suppose Base looked like this:

class Base
{
    public:
        virtual void func() throw(runtime_error) { cout << "Base!
"; }
};

Code snippet from ThrowListsVirtualMethodsBroken.cpp

Then you cannot override func() in Derived with a throw list like this:

class Derived : public Base
{
    public:
        virtual void func() throw(exception) // ERROR!
            { cout << "Derived!
"; }
};

Code snippet from ThrowListsVirtualMethodsBroken.cpp

exception is a superclass of runtime_error, so you cannot substitute an exception for a runtime_error.

Are Throw Lists Useful?

Given the opportunity to specify the behavior of a function in its prototype, it seems wasteful not to take advantage of it. The exceptions thrown from a particular function are an important part of its interface, and should be documented as well as possible.

Unfortunately, most of the C++ code in use today, including the Standard Library, does not follow this advice. That makes it difficult for you to determine which exceptions can be thrown when you use this code. Additionally, it is impossible to specify the exception characteristics of templatized functions and methods. When you don’t even know what types will be used to instantiate the template, you have no way to determine the exceptions that methods of those types can throw. As a final problem, the throw list syntax and enforcement is somewhat obscure.

Thus, we leave the decision up to you.

EXCEPTIONS AND POLYMORPHISM

As described earlier, you can actually throw any type of exception. However, classes are the most useful types of exceptions. In fact, exception classes are usually written in a hierarchy, so that you can employ polymorphism when you catch the exceptions.

The Standard Exception Hierarchy

You’ve already seen several exceptions from the C++ standard exception hierarchy: exception, runtime_error, and invalid_argument. Figure 10-3 shows the complete hierarchy:

FIGURE 10-3

All of the exceptions thrown by the C++ Standard Library are objects of classes in this hierarchy. Each class in the hierarchy supports a what() method that returns a const char* string describing the exception. You can use this string in an error message.

All the exception classes except for the base exception require you to set in the constructor the string that will be returned by what(). That’s why you have to specify a string in the constructors for runtime_error and invalid_argument. Now that you know what the strings are used for, you can make them more useful. Here is an example where the string is used to pass the full error message back to the caller:

void readIntegerFile(const string& fileName, vector<int>& dest)
    throw(invalid_argument, runtime_error)
{
    ifstream istr;
    int temp;
    istr.open(fileName.c_str());
    if (istr.fail()) {
        // We failed to open the file: throw an exception.
        string error = "Unable to open file " + fileName;
        throw invalid_argument(error);
    }
    // Read the integers one by one and add them to the vector.
    while (istr >> temp) {
        dest.push_back(temp);
    }
    if (istr.eof()) {
        // We reached the end-of-file.
        istr.close();
    } else {
        // Some other error. Throw an exception.
        istr.close();
        string error = "Unable to read file " + fileName;
        throw runtime_error(error);
    }
}
int main()
{
    // Code omitted
    try {
        readIntegerFile(fileName, myInts);
    } catch (const invalid_argument& e) {
        cerr << e.what() << endl;
        return 1;
    } catch (const runtime_error& e) {
        cerr << e.what() << endl;
        return 1;
    }
    // Code omitted
}

Code snippet from ExceptionsAndPolymorphismUsingWhat.cpp

Catching Exceptions in a Class Hierarchy

The most exciting feature of exception hierarchies is that you can catch exceptions polymorphically. For example, if you look at the two catch statements in main() following the call to readIntegerFile(), you can see that they are identical except for the exception class that they handle. Conveniently, invalid_argument and runtime_error are both subclasses of exception, so you can replace the two catch statements with a single catch statement for class exception:

try {
    readIntegerFile(fileName, myInts);
} catch (const exception& e) {
    cerr << e.what() << endl;
    return 1;
}

Code snippet from ExceptionsAndPolymorphismCatchingPolymorphicallyCorrectOne.cpp

The catch statement for an exception reference matches any subclasses of exception, including both invalid_argument and runtime_error. Note that the higher in the exception hierarchy that you catch exceptions, the less specific is your error handling. You should generally catch exceptions at as specific a level as possible.

When you catch exceptions polymorphically, make sure to catch them by reference. If you catch exceptions by value, you can encounter slicing, in which case you lose information from the object. See Chapter 8 for details on slicing.

When more than one catch clause is used, the catch clauses are matched in syntactic order as they appear in your code; the first one that matches, wins. If one catch is more inclusive than a later one, it will match first, and the more restrictive one, which comes later, will not be executed at all. Therefore, you should place your catch clauses from most restrictive to least restrictive order. For example, suppose that you want to catch invalid_argument from readIntegerFile() explicitly, but leave the generic exception match for any other exceptions. The correct way to do so is like this:

try {
    readIntegerFile(fileName, myInts);
} catch (const invalid_argument& e) { // List exception subclass first.
    // Take some special action for invalid filenames.
} catch (const exception& e) { // Now list exception
    cerr << e.what() << endl;
    return 1;
}

Code snippet from ExceptionsAndPolymorphismCatchingPolymorphicallyCorrectTwo.cpp

The first catch statement catches invalid_argument exceptions, and the second catches any other exceptions of type exception. However, if you reverse the order of the catch statements, you don’t get the same result:

try {
    readIntegerFile(fileName, myInts);
} catch (const exception& e) { // BUG: catching superclass first!
    cerr << e.what() << endl;
    return 1;
} catch (const invalid_argument& e) {
    // Take some special action for invalid filenames.
}

Code snippet from ExceptionsAndPolymorphismCatchingPolymorphicallyIncorrect.cpp

With this order, any exception of a class that subclasses exception is caught by the first catch statement; the second will never be reached. Some compilers issue a warning in this case, but you shouldn’t count on it.

Writing Your Own Exception Classes

There are two advantages to writing your own exception classes.

1. The number of exceptions in the C++ Standard Library is limited. Instead of using an exception class with a generic name, such as runtime_error, you can create classes with names that are more meaningful for the particular errors in your program.

2. You can add your own information to these exceptions. The exceptions in the standard hierarchy allow you to set only an error string. You might want to pass different information in the exception.

We recommend that all the exception classes that you write inherit directly or indirectly from the standard exception class. If everyone on your project follows that rule, you know that every exception in the program will be a subclass of exception (assuming that you aren’t using third-party libraries that break this rule). This guideline makes exception handling via polymorphism significantly easier.

For example, invalid_argument and runtime_error don’t capture very well the file opening and reading errors in readIntegerFile(). You can define your own error hierarchy for file errors, starting with a generic FileError class:

class FileError : public runtime_error
{
    public:
        FileError(const string& fileIn)
            : runtime_error(""), mFile(fileIn) {}
        virtual const char* what() const noexcept { return mMsg.c_str(); }
        string getFileName() { return mFile; }
    protected:
        string mFile, mMsg;
};