if(p==NULL)
abort

This article shows how to build a provisional implementation of the mechanism with a state of the art compiler. The code can be used in real projects, if you cannot wait for the official version.

Exception handling uses three additional keywords: try, catch, and throw. try and catch are always together defining a handler. That is, the handler "tries" a piece of code, and is prepared to "catch" a list of possible errors. The code looks like

try {
    f1();
    f2();
    ...
    etc.
}
catch (Error of type A) {
    ...
}
catch (Error of type B) {
    ...
}

// Normal continuation point
...

To signal an error, the code executed inside the try block can "throw" an exception. For instance,

fd = fopen (...);
if(fd == NULL)
throw (Error of type X);

if(error in try block) {
   switch(errno) {
      case 1:
         ...
         etc
   }
}

main() {
   try {
      f();
   }
   catch (An_Exception) {
      ...
   }
}
void  f() { g(); }
void g() { throw ( An_Exception ); }

In other words, throwing an exception transfers control to the last handler entered. If there is no catch matching the exception, the program calls a function named unexpected. If there is no handler, the program calls a function named terminate.

By default, unexpected calls terminate, and terminate calls abort. With the functions set_unexpected and set_terminate this can be changed by user-supplied implementations.

The implementation differs from the classical method in two important ways:

1. After throwing an exception, a special action is taken.

2. The jump to the handler breaks all the rules. Actually, it is a non-local goto, transferring control directly from throw to the appropriate catch block. (This is the delicate side of this mechanism.)

Throwing an exception is like putting a message in a bottle. The castaway launching the bottle has no idea if anyone will get the message, but is sure this is the best thing to do.

In C++, exception handling is particularly useful when treating errors in object constructors. For instance, a constructor implementation of the class

class A: public B {
   ...
public:
   A();
}

A::A() : B()
{

   // construct A.
   // The B part of A should be ready

   // Check B construction
   if(status != OK) {
      my_status = ~OK;
      return;
   }

   // Proceed with A construction
   ...
}

If somebody wants to derive a class from A, he is faced with the same problem. A user of class A has also to check if its construction is OK before using the object, otherwise he is opening the door for a bug. In other words, with this approach errors are not encapsulated.

Using exceptions, A's constructor looks like any simple constructor. That is,

A::A() : B()
{
   // Proceed with A construction
   ...
}

try {
   A a;
   //or
   A* pa = new A;
}
catch(Bad_B) {
   delete pa;
   ...
}

1. throw an_obj;

2. throw;

3. f() throw (type1, type2, etc.) {

//function body ...

Item 1 was used in the previous examples. an_obj is the object passed to the handler. The type of this object is used to select the catch block. For instance,

class AnError;

f() {
   AnError err;
   ...
   throw err;
   ...
}

f() {
   ...
   throw AnError();
   ...
}

catch (AnError) {
   throw;   // Throws AnError, with the object originally passed
}

void f() throw (A, B)
{
   // Body of f()
}

void f()
{
   try {
      // Body of f()
   }
   catch(A) {throw;}
   catch(B) {throw;}
}

try {
   ...
}
catch(AnError) {
   // Your handler
   ...
}

catch(AnError& obj) {
   // Your handler using obj values and services
   ...
}

#include.h

int setjmp(jmp_buf env);
void longjmp(jmp_buf env, int retval);

For instance, in the following code, main starts saving the current environment with setjmp. As this is a direct invocation, setjmp returns 0. Then f is called. Finally, g is called and longjmp is executed. Here the normal flow of the program is interrupted. Everything is reset to the state it was in when env was saved, so the next instruction is the evaluation of the if statement in main, with the only difference being that now setjmp returns 1 (longjmp's second argument).

#include.h
static jmp_buf env;
void g()
{
   longjmp(env, 1);
   // Never reach this point
}

void f()
{
   g();
   cout< "Return from g(). Never happens";
}

main()
{
   if(setjmp(env) == 0) {
      f();
   }
   else {
      cout < "Violent return\n";
   }
}

The formal definition of the mechanism prevents this, saying that as control passes from a throw point to handler, destructors are invoked for all objects fully constructed on the path from try to throw.

Unfortunately, this is not the case here. To use this model you have to be careful that the objects created in between are properly destroyed. A partial solution is to derive dangerous classes from an Undo class with virtual destructor, and do some kind of garbage collection with them.

{
   CdFile in("my_file");
   FuelType ft;

   try {
      in >ft;
   }
   catch(what you can) {
   }
}