Bruce Eckel - Thinking In C++. Volume 2 - Practical Programming

This chapter examines C’s approach to error handling (such as it is), discusses why it did not work well for C, and explains why it won’t work at all for C++. This chapter also covers try, throw, and catch, the C++ keywords that support exception handling .

In most of the examples in these volumes, we use assert( )as it was intended: for debugging during development with code that can be disabled with #define NDEBUGfor the shipping product. Runtime error checking uses the require.hfunctions ( assure( )and require( )) developed in Chapter 9 in Volume 1. These functions are a convenient way to say, «There’s a problem here you’ll probably want to handle with some more sophisticated code, but you don’t need to be distracted by it in this example.» The require.hfunctions might be enough for small programs, but for complicated products you might need to write more sophisticated error-handling code .

Error handling quite straightforward in situations in which you know exactly what to do because you have all the necessary information in that context. Of course, you just handle the error at that point .

The problem occurs when you don’t have enough information in that context, and you need to pass the error information into a different context where that information does exist. In C, you can handle this situation using three approaches: .

1.Return error information from the function or, if the return value cannot be used this way, set a global error condition flag. (Standard C provides errnoand perror( )to support this.) As mentioned earlier, the programmer is likely to ignore the error information because tedious and obfuscating error checking must occur with each function call. In addition, returning from a function that hits an exceptional condition might not make sense.

2.Use the little-known Standard C library signal-handling system, implemented with the signal( )function (to determine what happens when the event occurs) and raise( )(to generate an event). Again, this approach involves high coupling because it requires the user of any library that generates signals to understand and install the appropriate signal-handling mechanism; also in large projects the signal numbers from different libraries might clash.

3.Use the nonlocal goto functions in the Standard C library: setjmp( )and longjmp( ). With setjmp( )you save a known good state in the program, and if you get into trouble, longjmp( )will restore that state. Again, there is high coupling between the place where the state is stored and the place where the error occurs.

When considering error-handling schemes with C++, there’s an additional critical problem: The C techniques of signals and setjmp( )/ longjmp( )do not call destructors, so objects aren’t properly cleaned up. (In fact, if longjmp( )jumps past the end of a scope where destructors should be called, the behavior of the program is undefined.) This makes it virtually impossible to effectively recover from an exceptional condition because you’ll always leave objects behind that haven’t been cleaned up and that can no longer be accessed. The following example demonstrates this with setjmp/longjmp: .

//: C01:Nonlocal.cpp

// setjmp() & longjmp()

#include

#include

using namespace std;

class Rainbow {

public:

Rainbow() { cout << «Rainbow()» << endl; }

~Rainbow() { cout << «~Rainbow()» << endl; }

};

jmp_buf kansas;

void oz() {

Rainbow rb;

for(int i = 0; i < 3; i++)

cout << «there's no place like home\n»;

longjmp(kansas, 47);

}

int main() {

if(setjmp(kansas) == 0) {

cout << «tornado, witch, munchkins...\n»;

oz();

} else {

cout << «Auntie Em! "

<< "I had the strangest dream..."

<< endl;

}

} ///:~

The setjmp( )function is odd because if you call it directly, it stores all the relevant information about the current processor state (such as the contents of the instruction pointer and runtime stack pointer) in the jmp_bufand returns zero. In this case it behaves like an ordinary function. However, if you call longjmp( )using the same jmp_buf, it’s as if you’re returning from setjmp( )again—you pop right out the back end of the setjmp( ). This time, the value returned is the second argument to longjmp( ), so you can detect that you’re actually coming back from a longjmp( ). You can imagine that with many different jmp_bufs, you could pop around to many different places in the program. The difference between a local goto(with a label) and this nonlocal goto is that you can return to any pre-determined location higher up in the runtime stack with setjmp( )/ longjmp( )(wherever you’ve placed a call to setjmp( )) .

The problem in C++ is that longjmp( )doesn’t respect objects; in particular it doesn’t call destructors when it jumps out of a scope. [1] You might be surprised when you run the example—some C++ compilers have extended longjmp( ) to clean up objects on the stack. This behavior is not portable. Destructor calls are essential, so this approach won’t work with C++. In fact, the C++ standard states that branching into a scope with goto(effectively bypassing constructor calls), or branching out of a scope with longjmp( )where an object on the stack has a destructor, constitutes undefined behavior .

If you encounter an exceptional situation in your code—that is, one in which you don’t have enough information in the current context to decide what to do—you can send information about the error into a larger context by creating an object that contains that information and "throwing" it out of your current context. This is called throwing an exception . Here’s what it looks like: .

//: C01:MyError.cpp

class MyError {

const char* const data;

public:

MyError(const char* const msg = 0) : data (msg) {}

};

void f() {

// Here we "throw" an exception object:

throw MyError("something bad happened");

}

int main() {

// As you’ll see shortly,

// we’ll want a "try block" here:

f();

} ///:~

MyErroris an ordinary class, which in this case takes a char*as a constructor argument. You can use any type when you throw (including built-in types), but usually you’ll create special classes for throwing exceptions .

The keyword throwcauses a number of relatively magical things to happen. First, it creates a copy of the object you’re throwing and, in effect, "returns" it from the function containing the throw expression, even though that object type isn’t normally what the function is designed to return. A naive way to think about exception handling is as an alternate return mechanism (although you find you can get into trouble if you take the analogy too far). You can also exit from ordinary scopes by throwing an exception. In any case, a value is returned, and the function or scope exits .