What remains valid after failure
An operation can modify an object before a later step throws. Exception safety concerns the invariants, resources, and usable state left behind, rather than merely the presence of a catch statement.
The basic guarantee preserves invariants and avoids resource leaks while permitting state changes. The strong guarantee additionally preserves the protected state on failure. A non-throwing contract prevents exception propagation. These are promises about particular operations, not automatic properties of an entire class.
Protect resources and organize commitment
Resource handles arrange cleanup during exception unwinding and reduce missed releases. Cleanup alone does not necessarily undo mutations already made to the protected object, so basic and strong guarantees require separate reasoning.
One strategy performs fallible work on a temporary copy and commits through a non-failing final operation. Abrahams also describes the copying cost of this approach. If commitment or rollback can itself throw, the same argument no longer establishes the strong guarantee.
Component guarantees must compose
A generic component depends on element types and other operations. Changing the throwing behavior of copying, swapping, or destruction can change what an enclosing operation can promise. A non-throwing swap assumption in one example is not universal.
Declaring a C++ function noexcept specifies an exception boundary; an escaping exception terminates the program. This declaration does not by itself establish that the intended work succeeds. Error reporting, recovery, and the function’s preconditions still require a concrete contract.