Exceptions are usually presented as a way to simplify error handling in user code: user code is supposed to split the error handling code which is usually multiplexed with the main code path from the normal non-error code. The following sample shows code with and without exceptions.

// Without exceptions
typedef enum {
  error_alloc,
  error,
  ok
} ErrorStatus;
class Automatic {};
class Foo 
{
public:
        ErrorStatus DoAction (void) {return ok;}
};
class Bar 
{
public:
        ErrorStatus DoAction (void) {return error;}
};

ErrorStatus f (void)
{
        Automatic a;
        Foo *foo = new Foo ();
        if (foo == 0) {
                // a's destructor invoked automatically upon exit.
  	        return error_alloc;
        }
        ErrorStatus status = foo->DoAction ();
        if (status != ok) {
                delete foo;
                // a's destructor invoked automatically upon exit.
                return status;
        }
        Bar *bar = new Bar ();
        if (bar == 0) {
                delete foo;
                // a's destructor invoked automatically upon exit.
   	        return error_alloc;
        }
        status = bar->DoAction ();
        if (status != ok) {
                delete foo;
                delete bar;
                // a's destructor invoked automatically upon exit.
                return status;
        }
        delete foo;
        delete bar;
        // a's destructor invoked automatically upon exit.
        return ok;
}

int main (int argc, char *argv[])
{
        ErrorStatus status;
        status = f ();
        if (status != ok) {

        }
        return 0;
}

and with exceptions:

class Error {};
class Automatic {};
class Foo
{
public:
	void DoAction() throw(Error) { throw Error(); }
};
class Bar 
{
public:
	void DoAction() throw(Error) { throw Error(); }
};

void f()
{
	Foo* foo = 0;
	try {
		Automatic a;
		foo = new Foo;
		foo->DoAction();
		Bar* bar = 0;
		try {
			bar = new Bar;
			bar->DoAction();
		} catch (...) {
			delete bar;
			throw;
		}
		delete foo;
		delete bar;
		// a's destructor invoked automatically after leaving this scope
	} catch (...) {
		delete foo;
		throw;
	}
}
int main (int argc, char *argv[])
{
        try {
                f ();
	} catch (Error &e) {

        }
}

Both of these code listings try to invoke multiple methods on multiple objects which can all trigger errors. The errors are caught by the Bar method, they are handled localy by freeing the allocated memory and are propagated to the caller in case the caller might want to do something with it.

The syntax for the exception version seems rather straightforward (we'll revisit exception throwing syntax and semantics as well as exception catching and propagation syntax and semantics in the following sections): To return an error, rather than execute the statement return error;, you execute the statement throw Error ();. At this point, the C++ runtime is triggered and unwinds the call stack: it parses the stack from the inner-most function to the outer-most function and invokes the first code block identified by a matching catch statement in one of these functions. The unwinding stops when either the C++ runtime has found a matching catch block which does not rethrow the exception or when it reaches the top of the function stack. At each level, the unwinding routine invokes the destructors of any temporary variables left on the stack.

This process is absolutely similar in terms of functionality to the previous exception-free code which returned from the function as soon as an error was found and propagated the error code to its calling function, hoping that someone higher up in the call hierarchy knows better what to do with this error:

Of course, there are a number of rather subtle differences:

The syntax to throw exceptions might seem at first simple but, as the other bits and pieces of exception-related syntax, it has numerous subtle points.

The throw keyword used to throw exceptions actually has 3 different uses:

Interestingly, the seemingly simple syntax used to throw an exception is a bit more complicated than it looks. The exact definition of this syntax is: throw assignment-expression ^[1] . The static type of the assignment-expression is then used to initialize a temporary object of that type (through the type's copy-constructor) into a magic memory location which must stay valid during the subsequent unwinding. The magic memory location used is, of course, completely implementation-dependent. The temporary object is destroyed (that is, its destructor is first invoked and then its magic memory location is freed) when the stack unwinding completes.

The C++ specification suggests that the parameter to the throw statement can be viewed as an argument to a function call named throw. The syntax described above can thus be considered equivalent to throw (assignment-expression); which means that it is possible to replace the assignment-expression with anything used in the parameters to a normal function call. Most notably, the following sample code shows a few interesting examples:

void function (void) {
        // void bar (Foo foo);
        Foo foo = Foo ();
        bar (foo);
}
void function (void) {
        // void bar (Foo *foo);
        Foo *foo = new Foo ();
        bar (foo);
}
void function (void) {
        // void bar (Foo foo);
        bar (Foo ());
}
void function (void) {
        // void bar (Foo *foo);
        bar (new Foo ());
}

All these examples can be re-written with throw. They are commented below.

void function (void) {
        // push a copy of the foo object on the stack and invoke throw.
        Foo foo = Foo ();
        throw foo; // 1
}
void function (void) {
        // push a copy of the foo pointer on the stack and invoke throw.
        Foo *foo = new Foo ();
        throw foo; // 2
}
void function (void) {
        // allocate the foo object on the stack, constructs it and invoke throw.
        throw Foo (); // 3
}
void function (void) {
        // call new to allocate memory, construct this memory, push a copy
        // of the pointer returned by new on the stack, invoke throw.
        throw new Foo (); // 4
}

To summarize, it is important to understand that the exception object received by each matching catch block is a copy of the original exception object, created in the throw statement. It is thus vital that both its copy constructor and its destructor (to destroy the copies) are available to the program. The GNU C++ compiler will issue a warning if this not the case. It is also vital to understand that if you use a pointer as the exception object, the problem of freeing the memory it points it must be solved.

Given all these constraints, I'd suggest to always throw a class type (don't try to throw things such as int or const char *) and to never throw a pointer to such a class type. This will ensure that the memory used by exception objects will be automatically managed by the C++ compiler and its runtime, thus reducing potential bugs.

The syntax to declare a block of code as being able to catch an exception being thrown in another block of code is not as straightforward as most texts lead you to believe. The main syntax is, of course, pretty simple:

// catch all exceptions
try {
  // code which throws an exception 
} catch (...) {
  // code which catches any exception 
}

// catch only a given type of exceptions
try {
  // code which throws an exception 
} catch (const Excp &e) {
  // code which catches only exceptions of type const Excp 
}

The catch handler catches either all exceptions if the exception specification is ... or only a given exception type as specified by the exception specification. A handler matches an exception type if both underlying types are intuitively compatible in a way similar to that of a function call and its arguments. ^[2] The code in the catch handler can then access a copy of the original exception object. If this catch handler does not decide to progate the original exception with an empty throw; statement, it can throw another new exception (the original exception object is often copied into the new exception object to keep information about where the exception comes from) or not throw anything in which case stack unwinding stops and resumes after the catch block.

Catching exceptions can become interesting when you look at the more subtle syntax for the so-called function-try:

C::C(int ii, double id)
  try
    : i(f(ii)), d(id) // initializer list.
{
  //  constructor function body
}
  catch (...)
{
  //  handles exceptions thrown from the ctor-initializer
  //  and from the constructor function body
}

This function-try is used to catch exceptions thrown either during the initialization of the members of an object of during the execution of the constructor body of this object. In the sample code above, the catch block will be executed if an exception is thrown during the construction of the initializer list or during the excution of the function body. The exception is automatically rethrown when control reaches the end of the catch block. This means that it is impossible to actually catch exceptions and stop their propagation in a function-try-block which kind of defeats the whole purpose of a catch block! ^[3]

Robert Schmidt discusses the details of this rather surprising behavior in Part 14 of his C++ exceptions articles (se e the section called “References”).

A lot of work, sweat and saliva was dedicated to discover and describe programming idioms to ease the work of writing exception-safe code. Most texts (the interested reader will find useful references in the section called “References”) which deal with this problem distinguish between:

The focus is on writing all the code which lies between the throw and the corresponding catch statement. As you probably have noticed it, the same problem exists in code with uses exceptions and code which does not uses them. In both cases, the programmer must be careful to free all localy allocated ressources when the error code path is taken which is always a chore and error-prone.

What I have always found fascinating and rather surprising is that all the techniques developed to improve the look of code which must provide exception safety can be applied as-is to code which does not use exceptions to propagate program errors. The main technique used by exception safety code is to build upon one of the properties of the exception specification: all automatic variables locally allocated are destroyed upon stack unwinding. While this property can be seen by most readers as the source of all problems (pointers are destroyed but not the data they point to), it is paradoxically also the source of the solution.

The solution lies in what everyone calls smart pointers: while wide use of smart pointers makes templates mandatory, it is possible to understand the basic mechanism of these small object classes without using any templates.

A smart pointer is a small class which is used to hold a pointer to another object:

class Error {};

class Foo 
{
public:
  void Action (void) {throw Error ();}
};

class FooPtr
{
public:
  FooPtr (Foo *ptr) {m_ptr = ptr;}
  ~FooPtr () {delete m_ptr;}
  Foo *GetFoo (void) {return m_ptr;}
private:
  Foo *m_ptr;
};

static void dumb (void)
{
  Foo *ptr = new Foo ();
  try {
    ptr->Action ();
  } catch (Error &e) {
    delete ptr;
  }
}

static void smart (void)
{
  FooPtr ptr (new Foo ());
  ptr.GetFoo ()->Action ();
  // FooPtr's destructor is invoked upon exit of the function code block.
  // it destroys automatically the object it points to.
  // If an exception arises, FooPtr's destructor is also invoked because it
  // is an automatic local variable.
}

int main (int argc, char *argv[])
{
  dumb ();
  try {
    smart ();
  } catch (Error &e) {
    // handle.
  }
}

The key point to notice here is that the FooPtr class is used to associate a destructor to a pointer to the Foo class which is thus automatically invoked by the stack unwinding code during exception propagation.

Of course, the above-described smart pointer class can be rewritten to the following less easy to understand code which has the nice side-effect to allow for much nicer-looking client code:

class Error {};

class Foo 
{
public:
  void Action (void) {throw Error ();}
};

class FooPtr
{
public:
  FooPtr (Foo *ptr) {m_ptr = ptr;}
  ~FooPtr () {delete m_ptr;}
  Foo *operator-> () {return m_ptr;}
private:
  Foo *m_ptr;
};

static void smart (void)
{
  FooPtr ptr (new Foo ());
  ptr->Action ();
  // FooPtr's destructor is invoked upon exit of the function code block.
  // it destroys automatically the object it points to.
  // If an exception arises, FooPtr's destructor is also invoked because it
  // is an automatic local variable.
}

int main (int argc, char *argv[])
{
  try {
    smart ();
  } catch (Error &e) {
    // handle.
  }
}

Here, the call to GetFoo () is replaced with the operator ->. If you really want to design a nice smart pointer class, it will clearly require a bit more code and thinking (look at the template class auto_ptr in the C++ standard library) but the basic idea will stay the same.

As I mentioned earlier, the idea of smart pointers can be used to rewrite the error-propagation code we wrote in the section called “What is an exception ?” (if you write smart pointer classes which override the == and -> operators):

// no exceptions
typedef enum {
        ok,
        error,
        error_alloc
} ErrorStatus;

class Foo
{
public:
        ErrorStatus Action (void) {return ok;}
};

class FooPtr
{
public:
        FooPtr (Foo *ptr) {m_ptr = ptr;}
        ~FooPtr () {delete m_ptr;}
        Foo *operator-> () {return m_ptr;}
        bool operator == (void * v) {return m_ptr == v;}
private:
        Foo *m_ptr;
};

class Bar
{
public:
        ErrorStatus Action (void) {return ok;}
};

class BarPtr
{
public:
        BarPtr (Bar *ptr) {m_ptr = ptr;}
        ~BarPtr () {delete m_ptr;}
        Bar *operator-> () {return m_ptr;}
        bool operator == (void * v) {return m_ptr == v;}
private:
        Bar *m_ptr;
};


ErrorStatus no_exceptions (void)
{
        FooPtr foo (new Foo ());
        if (foo == 0) {
                return error_alloc;
        }
        ErrorStatus status = foo->Action ();
        if (status != ok) {
                return status;
        }
        BarPtr bar (new Bar ());
        if (bar == 0) {
                return error_alloc;
        }
        status = bar->Action ();
        if (status != ok) {
                return status;
        }
 out:
        return status;
}

int main (int argc, char *argv[])
{
        ErrorStatus status;
        status = no_exceptions ();
        if (status != ok) {

        }
}

And the exception version:

// exceptions
class Error {};

class Foo
{
public:
  void Action (void) {throw Error ();}
};

class FooPtr
{
public:
        FooPtr (Foo *ptr) {m_ptr = ptr;}
        ~FooPtr () {delete m_ptr;}
        Foo *operator-> () {return m_ptr;}
        bool operator == (void * v) {return m_ptr == v;}
private:
        Foo *m_ptr;
};

class Bar
{
public:
  void Action (void) {throw Error ();}
};

class BarPtr
{
public:
        BarPtr (Bar *ptr) {m_ptr = ptr;}
        ~BarPtr () {delete m_ptr;}
        Bar *operator-> () {return m_ptr;}
        bool operator == (void * v) {return m_ptr == v;}
private:
        Bar *m_ptr;
};

void exceptions (void)
{
        FooPtr foo (new Foo ());
        foo->Action ();
        BarPtr bar (new Bar ());
        bar->Action ();
}

int main (int argc, char *argv[]) 
{
        try {
                exceptions ();
        } catch (Error &e) {

        }
}

Here, admitedly, the exception version of the code looks, erm, a bit more simple than the error-code based version of the code which is, at best, clutered with if statements (but it's clearly much nicer code since you do not have to worry about freeing the objects correctly in each different if case: it is automatically handled by the compiler).

As can be seen in the previous sections, while it might seem at first that code written to deal with program errors by using exceptions and code written using simple status error codes are very similar, it is not true anymore if you use a few relatively simple tricks: the exception-based code becomes much cleaner which is what exceptions were designed to deliver.

It was often pointed out that, while exceptions do provide nicer-looking code in a lot of cases, it is very difficult to write exception-safe code in all cases. Some people claim that programmers then spend most of their time thinking about how to write exception-safe code and not how to to write their application. What these people forget is that if they decide not to use exceptions, they still need to do something about their program errors: how do you propagate errors up to the piece of code which can deal with it ?

There are not many solutions:

I don't think that any of the above solutions provide a framework which might provide better-looking code than straight exception-based code.

A lot of other people dismiss exception-based code by complaining either about the performance hit or their compiler's compliance to the C++ standard. There isn't much I can do about standard compliance: as far as I can tell, gcc runs on quite a lot of platforms which means you should be able to get pretty good compliance on anything. EDG also sells its standard-compliant C++ frontend to a lot of companies which means you should be able to buy a pretty good compiler for your platforms unless it is very bizare. If you can't, then, what can I say ?

Measuring the performance of exception-based code is pretty difficult: the only interesting reference I could find is available in the section called “References”. I will probably try to do some measurements myself in another article.