Exception handling provides a way of transferring control and information from some point in the execution of a program to an handler associated with a point previously passed by the execution (in other words, exception handling transfers control up the call stack)
An exception can be thrown by a throw-expression, and many standard library functions, including memory allocation functions, are specified to throw exceptions to signal certain error conditions.
In order for exception to be caught, the throw-expression has to be inside a try-block or inside a function called from a try-block, and there has to be a catch clause that matches the type of the exception object.
Errors that arise during exception handling are handled by std::terminate and std::unexpected.
While throw-expression can be used to transfer control to an arbitrary block of code up the execution stack, for arbitrary reasons (similar to std::longjmp), its intended usage is error handling.
- Failures to establish invariants
- Failures to meet the postconditions
- Failures to meet the preconditions of the caller
In particular, this implies that the failures of constructors and most operators should be reported by throwing exceptions.
After the error condition is reported by a function, additional guarantees may be provided with regards to the state of the program. The following four levels of exception guarantee are generally recognized, which are strict supersets of each other:
- Nothrow (or nofail) exception guarantee -- the function never throws exceptions. This is expected of destructors and, typically, of move constructors.
- Strong exception guarantee -- If the function throws an exception, the state of the program is rolled back to the state just before the function call.
- Basic exception guarantee -- If the function throws an exception, the program is in a valid state. It may require cleanup, but all invariants are intact.
- No exception guarantee -- If the function throws an exception, the program may not be in a valid state: resource leaks, memory corruption, or other invariant-destroying errors may have occurred.
While objects of any complete type and cv pointers to void may be thrown as exception objects, all standard library functions throw anonymous temporary objects by value, and the types of those objects are derived (directly or indirectly) from std::exception. User-defined exceptions usually follow this pattern.
- H. Sutter (2004) "When and How to Use Exceptions" in Dr. Dobb's
- H.Sutter, A. Alexandrescu (2004), "C++ Coding Standards", Item 70
- B. Stroustrup (2000), "The C++ Programming Language"Appendix E"
- H. Sutter (2000) "Exceptional C++"
- D. Abrahams (2001) "Exception Safety in Generic Components"
- D. Abrahams (2001) "Error and Exception Handling"
- M. Cline, C++FAQ Lite 17.11
- S. Meyers (1996) "More Effective C++" Item 13
- M. Cline, C++FAQ Lite 17.12
- H.Sutter, A. Alexandrescu (2004) "C++ Coding Standards" Item 73