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: