Exception safety

As David Abrahams writes, "nobody ever spoke of 'error-safety' before C++ had exceptions." Exception safety for the C++ standard library was first formalized for STLport by Abrahams, establishing the basic safety/strong safety distinction. This was extended to the modern basic/strong/nothrow guarantees in a later proposal. == Background ==

Exceptions provide a form of non-local control flow, in that an exception may "bubble up" from a called function. This bubbling can cause an exception safety bug by breaking invariants of a mutable data structure, as follows: • A step of an operation on a mutable data structure modifies the data and breaks an invariant. • An exception is thrown and control "bubbles up", skipping the rest of the operation's code that would restore the invariant • The exception is caught and recovered from, or a finally block is entered • The data structure with broken invariant is used by code that assumes the invariant, resulting in a bug Code with a bug such as the above can be said to be "exception unsafe". == Classification ==

The C++ standard library provides several levels of exception safety (in decreasing order of safety): • Basic exception safety: Partial execution of failed operations can result in side effects, but all invariants are preserved. Any stored data will contain valid values which may differ from the original values. Resource leaks (including memory leaks) are commonly ruled out by an invariant stating that all resources are accounted for and managed. • No exception safety: No guarantees are made. Usually, at least basic exception safety is required to write robust code. Higher levels of safety can sometimes be difficult to achieve, and might incur an overhead due to extra copying. A key mechanism for exception safety is a finally clause, or similar exception handling syntax, which ensure that certain code is always run when a block is exited, including by exceptions. Several languages have constructs that simplify this, notably using the dispose pattern, named as using, with, or try-with-resources. == Example ==

Consider a smart vector type, such as C++'s or Java's . When an item is added to a vector , the vector must actually add to the internal list of objects and update a count field that says how many objects are in . It may also need to allocate new memory if the existing capacity isn't sufficient. Exception safety alternatives: ;No-throw guarantee: Implemented by ensuring that memory allocation never fails, or by defining the function's behavior on allocation failure (for example, by having the function return a boolean result indicating whether the insertion took place). ;Strong exception safety: Implemented by doing any necessary allocation first, and then swapping buffers if no errors are encountered (the copy-and-swap idiom). In this case, either the insertion of into succeeds, or remains unchanged despite the allocation failure. ;Basic exception safety: Implemented by ensuring that the count field is guaranteed to reflect the final size of . For example, if an error is encountered, the function might completely deallocate and reset its count field to zero. On failure, no resources are leaked, but 's old value is not preserved. ;No exception safety: An insertion failure might lead to corrupted content in , an incorrect value in the count field, or a resource leak. == References ==