Exceptions in C++

try {
 ...body...
} catch ( exceptionTypeSpecification1 exceptionVar1 ) {
 ...handler...
} catch ( exceptionTypeSpecification2 exceptionVar2 ) {
 ...handler...
} ...
  catch ( exceptionTypeSpecificationN exceptionVarN ) {
 ...handler...
} 

To raise an exception:

throw exceptionExpression;

// Catch any exception - irrespective of type
catch (...) {
 handler body;
}

// Only valid from within a handler:
// Rethrows the current exception
throw;

catch (E e) ...
catch (E& e) ...
catch (E* e) ...
catch (const E& e) ...
catch (const E *e) ...

void f() {
  Exception e;
  g(e);
  throw e;
}

void g(Exception& e) {
  // do something with e
}

void h() {
  try {
    f();
  catch (Exception& e) {
    // do something with e
  }
}

In contrast, when the exception e is raised, in the dynamic extent of h, the catch clause of h will capture the exception e. A copy of e will still be performed, because when the exception unwinds the stack, the local variable e will be destroyed and de-allocated. Therefore, when the catch clause is reached, the original e object does not exist anymore.

C++ specifies that an object thrown is always copied.

Exception Specifications

class C {
  int m(int p) throws ();
  int n(int q) throws (exception, ioexception);
};

There are some issues which make the use of exception specifiers not convenient (discussed in the references). One form, however, is particularly important, especially for documentation purposes:

class C {
  ~C() throws();  // nothrow warranty
};

Why Use Exceptions

1. Where the error could occur
2. In any place that invokes any function in which an error may occur

const int OK = 1;
const int ERROR1 = -1;
const int ERROR2 = -2;

int f() {
  int g = g();
  if (g != OK) return g;
  int h = h();
  if (h != OK) return h;
  // do something
  ...
  return OK;
}

int g() {
 if (testError) return ERROR1;
 // do something
 ...
 return OK; 
}

int h() {
  if (testError2) return ERROR2;
  // do something
  ...
  return OK;
}

When to Use Exceptions

1. They should not be raised for cases that are expected to happen on "legal" data
2. They should be raised when an operation cannot find any reasonable way to deal with a situation locally.
3. They should be raised only when the try/catch block is not in the same context as the "throw" location. (Otherwise, instead of a try/catch, use regular if constructs to avoid the exception.)

How to Deal with Exceptions

1. Using try/catch
2. Using "resource managers" -- that is, classes whose destructors "clean up" resources.

Exception Safe Code

1. When invoking code that can potentially throw exceptions, should the caller code deal with the exception or let it propagate upwards to another caller.
2. If the exception is caught, the caller should "clean up" resources it has allocated and decide whether to restart the invocation (retry), or abort by propagating again the exception (throw) or another exception (exception translation).

1. Basic Guarantee: Even in the presence of exceptions thrown by the callee, the caller does not leak resources. This implies that the caller object will remain in a destructible and usable state even if an exception is thrown.
2. The Strong Guarantee: If an exception is thrown, the operation has no effects on the object. This corresponds to a "commit or rollback" semantics for the operations on the object.
3. Nothrow Guarantee: The operation will not emit an exception and any circumstances.

An Exception-Safe Stack Class

The Stack Interface

template <class T> class Stack {
public:
  Stack();
  ~Stack();

  Stack(const Stack&);            // Copy constructor
  Stack& operator=(const Stack&); // Assignment operator

  // Accessors
  size_t Size() const;

  // Mutators
  void Push(const T&);
  T Pop(); // If empty throws exception
};

An unsafe Implementation

template <class T> class Stack {
public:
  Stack();
  ~Stack();

  Stack(const Stack&);            // Copy constructor
  Stack& operator=(const Stack&); // Assignment operator

  // Accessors
  size_t Size() const;

  // Mutators
  void Push(const T&);
  T Pop(); // If empty throws exception

private:
  T* v_;          // Pointer to a memory area big enough for
  size_t vsize_;  // vsize_ T's
  size_t vused_;  // Number of T's actually in use
};

// Default constructor
template<class T>
Stack<T>::Stack() : v_(0), vsize_(10), vused_(0) {
  v_ = new T[vsize_];
}

1. It allocates enough memory for vsize_ T objects on the heap.
2. It then invokes the default constructor of each T object vsize_ times.

1. There is not enough room in the heap. a bad_alloc exception is thrown.
2. One of the vsize_ constructors throws an exception.

1. If a bad_alloc exception is thrown by new[], no memory is allocated (this is a guarantee provided by new[] in C++), so there is no reason to clean up. The constructor exits and the Stack object is never constructed.
2. If one of the T constructors throws an exception, any of the T objects that were properly constructed will be properly destroyed, one by one, and finally operator delete[] will be invoked to release the memory allocated by new[]. Note however, that we impose here the requirement that the T destructor, ~T(), does not throw exceptions, otherwise, the clean up of the constructed T objects might not end up well. We therefore have a requirement on T that ~T() implements the nothrow() guarantee.
3. If any exception is thrown, we are left in a consistent state: there is no object Stack ever constructed, so we do not need to worry about leaving it in a "safe state" because there is no state.

// Default constructor
template<class T>
Stack<T>::Stack() : v_(new T[10]), vsize_(10), vused_(0) {
}

Destructor

template<class T> Stack<T>::~Stack() throws() {
  delete[] v_; 
}

Copy

template <class T> Stack<T>::Stack(const Stack<T>& other) {
  v_ = new T[other.vsize_];  // can throw
  vsize_ = other.vsize_;
  vused_ = other.vused_;
  for (int i = 0; i < vused_; ++i) {
      v_[i] = other.v_[i];     // can throw
  }    
}

A similar problem arises in the copy assignment. To avoid this problem, we introduce an auxiliary function which is responsible to manage memory allocation:

template <class T> T* NewCopy(const T* src, size_t srcsize, size_t destsize) {
  assert( destsize >= srcsize);
  T* dest = new T[destsize];
  try {
    copy(src, src+srcsize, dest);
  } catch (...) {
    delete[] dest;  // nothrow
    throw;
  }
  return dest;
}

template <class T> Stack<T>::Stack(const Stack<T>& other) :
  v_( NewCopy( other.v_, other.vsize_, other.vsize_ ),
  vsize_( other.vsize_ ),
  vused_( other.vused_ ) {
}

template <class T> Stack<T>::operator=(const Stack<T>& other) {
  if (this != &other) {
    T* v_new = NewCopy( other.v_, other.vsize_, other.vsize_ );
    delete[] v_;  // no throw
    v_ = v_new;
    vsize_ = other.vsize_;
    vused_ = other.vused_;
  }
  return *this;  // safe - no copy
}

Mutation Operations

template <class T> void Stack<T>::Push(const T& t) {
  if (vused_ == vsize_) {
    T* v_new = NewCopy( v_, vsize_, vsize_*2+1 ); // Can throw
    delete[] v_;  // no throw
    v_ = v_new;   // acquire new resource
    vsize_ = vsize_*2+1;
  }
  v_[vused_] = t; // Can throw
  ++vused_;
}

If NewCopy completes, we acquire the new vector using nothrow operations only. When the if block completes, the stack is in a consistent state and no resource is outstanding.

The copy assignment operator used to copy the argument into the stack can throw. In this case, if we required that the T operator= is weakly safe, nothing wrong happens to the stack: vused_ is not updated, the slot vused_ remains in deletable state and no resources are leaked (because T::operator= is weakly safe).

The pop operation is more problematic: The naive implementation is not safe:

template <class T> T Stack<T>::Pop() {
  if (vused_ == 0) {
    throw "Empty stack";
  }
  T t(v_[vused_]); // Can throw
  --vused_;
  return t;        // Can throw
}

The solution is to modify the signature and to introduce (as is done in STL) two operations - one for each aspect of the work Pop() was supposed to do:

1. T& top(); // Return a reference to the top element - throws if empty
2. void pop(); // Make top element not accessible anymore - no return

Requirements on Contained Type T

1. T has a default constructor (can throw).
2. T has a weakly safe copy constructor.
3. T has a weakly safe assignment operator.
4. ~T does not throw.

We can reduce the requirements on T if we notice that the default constructor and assignment operator are used because we have define v_ as an array of T. If instead we look at T as just a memory area and manage in-place object construction, we can reduce the requirements on T.

Containers which are strongly exception-safe with minimal requirements on the contained type T are provided in some STL implementations. The best such implementation is available in STLPort, an open-source implementation of STL with strong exception guarantees.

General Exception-Safety Rules

1. Never allow an exception to escape from a destructor, or from an overloaded operator delete() or operator delete[]().
2. Always use the "resource acquisition is initialization" idiom to isolate resource ownership and management.
3. In each function, take all the code that might throw an exception and do all the work safely off to the side. Only when you know that the real work has succeeded, should you modify your program state and clean up using nothrow operations only.

References

C++ Exceptions

1. Exception-Safe Class Design, Part 1: Copy Assignment, H. Sutter, July 1999 (Definition of the three-level exception safety guarantees, how to write an exception-safe copy assignment operator using the P_impl idiom).
2. Simplify your Exception-Safe Code, Andrei Alexandrescu and Petru Marginean, C/C++ Users Journal, Dec 2000 (Introduces the ScopeGuard template to inject resource clean up code without writing resource manager classes - essential reading, extremely useful in practical programming.)

   Note: The very popular ScopeGuard class has been since integrated into the Loki library.

3. ACID Programming, H. Sutter, Sept 1999. (Comparison of Exception-safe code with transaction management in databases.)
4. Pattern Languages for Handling C++ Resources in an Exception-Safe Way, Harald M. Mueller, 2nd Usenix Conference on Object-Oriented Technologies (COOTS), 1996. (Classification of exception-safe techniques in C++).
5. How a C++ compiler implements exception handling, Vishal Koshhar, Apr 2002 (This gives the "machine level" view of exception handling in a Windows environment - very useful to understand the cost and details of exception handling.)
6. Exception Safety and Exception Specifications: Are they Worth it?, H. Sutter, June 2001 (Short answer: except as a documentation of the no-throw guarantee, not many reasons to use throw specifications in C++.)
7. Constructor Failures, H. Sutter, Jan 2000. (What happens when an exception is thrown inside the body of a constructor, and what to do about it.)
8. Exception-Safe Function Calls, H. Sutter, May 1999. (Make sure the order of execution of sub-expressions is understood otherwise resource release is impossible.)
9. Uncaught Exceptions, H. Sutter, Nov 1998. (When exceptions are not caught, what can be done in last resort).
10. Code Complexity - Part II, H. Sutter, Sep 1997.

Java Exceptions

1. Java Exceptions Tutorial (Sun)
2. Understanding Java Exceptions, Chuck Allison, C/C++ Users Journal, April 2001.