Manual error propagation becomes unnecessary

Error conditions in constructors can be handled consistently

Separation of data return channel and error return channel

Can improve runtime speed (Depends on usage)

Generally exceptions include more rich error/context information

Simplistic mechanism for handling errors at higher levels which know better how to recover from a problem

Exceptions can't be accidentally lost by forgetting to check a return value

Often results in code where the main operation being performed is easier to distinguish from the error handling code

May decrease runtime speed (Depends on usage)

Generally it is considered poor usage to use exceptions for additional data return mechanisms or for very common errors. They are often better used for erroneous conditions that do not occur regularly.

Introduces "hidden" execution control paths to code

This is one of the main disadvantages of using exceptions, but also some consider it an advantage as the resulting code will often be void of error handling code making the intended purpose of the code clearer. It is on error conditions in the presence of exceptions that it becomes unclear as to what execution path will be followed which may leave objects in undefined states etc.

Note: EDoc++ intends to provide a solution to this problem in the future by generating information about exception execution paths that can make these "hidden" paths visible through annotating source code with exception documentation.

Difficult to avoid resource leaks

Making good use of C++ destructors is a common way to avoid resource leaks. This is done by performing intialisation of resources in constructors and cleanup of the resources in destructors. This is a common pattern called Resource Acquisition Is Initialisation (RAII) pattern. More information on RAII can be found at: http://www.hackcraft.net/raii/ or the Wikipedia page at: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization.

Language provided safety mechanisms terminate the program upon failure and are not enforced at compile time

This termination property makes the usage of the function exception qualifiers very unhelpful. EDoc++ addresses this problem by emitting error messages for every exception that may emit from a function that is not allowed by that functions throw() specifier. This static source analysis can identify exception usages that may cause the program to terminate in this manner at "compile time" and allows developers to safely make use of the throws() qualifier without worrying about its dangerous side effects.

Exceptions thrown in certain locations or at certain points in time will cause program termination (E.g. Throwing from copy constructor in a catch statement, or throwing in a destructor while the stack is being un-wound)

EDoc++ will emit errors for conditions that cause these problems.

Note: The emission of errors for raising new exceptions while stack unwinding due to another exception is currently not implemented.

C++ code generally does not make use of a garbage collector and memory is easily leaked especially in the presence of exceptions.

This is often solved using smart pointers or only making use of the stack for constructing objects. This is really a specialisation of the "Difficult to avoid resource leaks" problem above. The solution is to make use of the RAII principle in the form of shared pointers as will be introduced into the C++0x spec or that are currently available in the boost shared_ptr.