There are a number of benefits to using exceptions for handling error conditions, some of which include:
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
The above advantages are a small representation of advantages obtained using exceptions. However there are also a number of disadvantages often associated with using exception error handling techniques. Some of these include:
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.
Within the C++ language there are also special considerations that make using exceptions more difficult and error prone than in other similar languages like Java. As a result adoption of exception usage within the C++ community is more reserved than in many other languages. Very few C++ projects make much use of exceptions due to the dangerous or time consuming nature of doing so. Some of the dangers of using exceptions for error handling specifically in C++ include:
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.
For additional information on advantages and disadvantages of using exceptions in C++ and also more information on using exceptions, see some of the links below:
@@@Brendon TODO: Look for better external links. Possibly remove some of these.