cout << "Auntie Em! "
<< "I had the strangest dream..."
<< endl;
}
} ///:~
When the throw statement in oz( ) executes, program control backtracks until it finds the catch clause that takes an int parameter, at which point execution resumes with the body of that catch clause. The most important difference between this program and Nonlocal.cpp is that the destructor for the object rb is called when the throw statement causes execution to leave the function oz( ).
There are two basic models in exception-handling theory: termination and resumption. In termination (which is what C++ supports), you assume the error is so critical that there’s no way to automatically resume execution at the point where the exception occurred. In other words, "whoever" threw the exception decided there was no way to salvage the situation, and they don’t want to come back.
The alternative error-handling model is called resumption, first introduced with the PL/I language in the 1960s[2].Using resumption semantics means that the exception handler is expected to do something to rectify the situation, and then the faulting code is automatically retried, presuming success the second time. If you want resumption in C++, you must explicitly transfer execution back to the code where the error occurred, usually by repeating the function call that sent you there in the first place. It is not unusual, therefore, to place your try block inside a while loop that keeps reentering the try block until the result is satisfactory.
Historically, programmers using operating systems that supported resumptive exception handling eventually ended up using termination-like code and skipping resumption. Although resumption sounds attractive at first, it seems it isn’t quite so useful in practice. One reason may be the distance that can occur between the exception and its handler; it is one thing to terminate to a handler that’s far away, but to jump to that handler and then back again may be too conceptually difficult for large systems on which the exception can be generated from many points.
Exception matching
When an exception is thrown, the exception-handling system looks through the "nearest" handlers in the order they appear in the source code. When it finds a match, the exception is considered handled and no further searching occurs.
Matching an exception doesn’t require a perfect correlation between the exception and its handler. An object or reference to a derived-class object will match a handler for the base class. (However, if the handler is for an object rather than a reference, the exception object is "sliced"— truncated to the base type — as it is passed to the handler; this does no damage but loses all the derived-type information.) For this reason, as well as to avoid making yet another copy of the exception object, it is always better to catch an exception by reference instead of by value[3]. If a pointer is thrown, the usual standard pointer conversions are used to match the exception. However, no automatic type conversions are used to convert from one exception type to another in the process of matching, for example:.
//: C01:Autoexcp.cpp
// No matching conversions
#include <iostream>
using namespace std;
class Except1 {};
class Except2 {
public:
Except2(const Except1&) {}
};
void f() { throw Except1(); }
int main() {
try { f();
} catch (Except2&) {
cout << "inside catch(Except2)" << endl;
} catch (Except1&) {
cout << "inside catch(Except1)" << endl;
}
} ///:~
Even though you might think the first handler could be used by converting an Except1 object into an Except2 using the constructor conversion, the system will not perform such a conversion during exception handling, and you’ll end up at the Except1 handler.
The following example shows how a base-class handler can catch a derived-class exception:.
//: C01:Basexcpt.cpp
// Exception hierarchies
#include <iostream>
using namespace std;
class X {
public:
class Trouble {};
class Small : public Trouble {};
class Big : public Trouble {};
void f() { throw Big(); }
};
int main() {
X x;
try {
x.f();
} catch(X::Trouble&) {
cout << "caught Trouble" << endl;
// Hidden by previous handler:
} catch(X::Small&) {
cout << "caught Small Trouble" << endl;
} catch(X::Big&) {
cout << "caught Big Trouble" << endl;
}
} ///:~
Here, the exception-handling mechanism will always match a Trouble object, or anything that is a Trouble (through public inheritance),[4] to the first handler. That means the second and third handlers are never called because the first one captures them all. It makes more sense to catch the derived types first and put the base type at the end to catch anything less specific.
Notice that these examples catch exceptions by reference, although for these classes it isn’t important because there are no additional members in the derived classes, and there are no argument identifiers in the handlers anyway. You’ll usually want to use reference arguments rather than value arguments in your handlers to avoid slicing off information.
Catching any exception
Sometimes you want to create a handler that catches any type of exception. You do this using the ellipsis in the argument list:.
Catch(...) {
cout << "an exception was thrown" << endl;
}
An ellipsis catches any exception, so you’ll want to put it at the end of your list of handlers to avoid pre-empting any that follow it.
Because the ellipsis gives you no possibility to have an argument, you can’t know anything about the exception or its type. It’s a "catchall." Such a catch clause is often used to clean up some resources and then rethrow the exception.
Re-throwing an exception
You usually want to re-throw an exception when you have some resource that needs to be released, such as a network connection or heap memory that needs to be deallocated. (See the section "Resource Management" later in this chapter for more detail). If an exception occurs, you don’t necessarily care what error caused the exception—you just want to close the connection you opened previously. After that, you’ll want to let some other context closer to the user (that is, higher up in the call chain) handle the exception. In this case the ellipsis specification is just what you want. You want to catch any exception, clean up your resource, and then re-throw the exception so that it can be handled elsewhere. You re-throw an exception by using throw with no argument inside a handler:.
2
Visual Basic supports a limited form of resumptive exception handling with its ON ERROR facility.
3
In fact, you might want to always specify exception objects by const reference in exception handlers. It’s very rare to modify and rethrow an exception. We are not dogmatic about this practice however.
4
Only