| Warning | ||
|---|---|---|
| ||
This practice is an incomplete work in progress. It may contain errors and should not be applied until this notice has been removed. |
Proper handling of errors and exceptional situations is essential for the continued correct operation of software (see ERR00-CPP. Adopt and implement a consistent and comprehensive error-handling policy). The preferred mechanism for reporting errors in a C++ program is exceptions (see ERR07-CPP. Use exception handling rather than error codes). A number of core language facilities, including dynamic_cast, operator new(), and typeid, report failures by throwing exceptions. In addition, the C++ standard library makes heavy use of exceptions to report several different kinds of failures. Few C++ programs manage to avoid using some of these facilities. Consequently, the vast majority of C++ programs must be prepared for exceptions to occur and must handle each appropriately (see ERR51-CPP. Handle all exceptions).
Because exceptions introduce code paths into a program that would not exist in their absence, it is important to consider the effects of code taking such paths and to avoid any undesirable effects that might arise otherwise. Some such effects include failure to release an acquired resource, thereby introducing a leak, and failure to reestablish a class invariant after a partial update to an object or even a partial object update while maintaining all invariants. Code that avoids any such undesirable effects is said to be be exception safe.
Based on the preceding effects, the following table distinguishes three kinds of exception safety guarantees in decreasing desirability:
Guarantee | Description | Example |
|---|---|---|
Strong | The strong exception safety guarantee is a property of an operation such that, in addition to satisfying the basic exception safety guarantee, if the operation terminates by raising an exception, it has no observable effects on program state. | |
Basic | The basic exception safety guarantee is a property of an operation such that, if the operation terminates by raising an exception, it preserves program state invariants and prevents resource leaks. | |
None | Code that provides neither the strong nor the basic exception safety guarantee is not exception safe. |
Code Because all exceptions thrown in an application must be handled, it is critical that thrown exceptions do not leave the program in an indeterminate state where invariants are violated. Whether handling an exception is used to control the termination of the program, or is an attempt to recover from an exceptional situation, a violated invariant leaves the program in a state where graceful continued execution is likely to introduce security vulnerabilities. Thus, code that provides no exception safety guarantee is unsafe and must be considered defective.
...
The following noncompliant code example shows a flawed copy assignment operator. The implicit invariants of the class are that the array member is a valid (possibly null) pointer and that the nelems member stores the number of elements in the array pointed to by array. The code is flawed because it fails to provide any exception safety guarantee. The function deallocates array and assigns the element counter, nelems, before allocating a new block of memory for the copy. As a result, if the new expression throws an exception, the function will have modified the state of both member variables in a way that violates the implicit invariants of the class. Consequently, such an object is in an indeterminate state and any operation on it, including its destruction, results in undefined behavior.
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
| SEI CERT C++ Coding Standard | ERR51-CPP. Handle all exceptions |
| MITRE CWE | CWE-703, Failure to Handle Exceptional Conditions |
...