Exception safety

Exception safety guarantees, originally formalized by David Abrahams,^[1][2] are a set of contractual guidelines that class library implementers and clients use when reasoning about exception handling safety in C++ programs. The principles are not restricted to C++ though, and also apply to any programming language that uses exceptions.

There are several levels of exception safety (in decreasing order of safety):^[3]

1. No-throw guarantee, also known as failure transparency: Operations are guaranteed to succeed and satisfy all requirements even in presence of exceptional situations. If an exception occurs, it will be handled internally and not observed by clients.
2. Strong exception safety, also known as commit or rollback semantics: Operations can fail, but failed operations are guaranteed to have no side effects so all data retain original values.^[4]
3. Basic exception safety, also known as no-leak guarantee: Partial execution of failed operations can cause side effects, but all invariants are preserved and no resources are leaked. Any stored data will contain valid values, even if data has different values now from before the exception.
4. 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.

Example

Consider a smart vector type, such as C++'s std::vector or Java's ArrayList. When an item x is added to a vector v, the vector must actually add x to the internal list of objects and update a count field that says how many objects are in v. It may also need to allocate new memory if the existing capacity isn't sufficient.

Exception safety alternatives:

• No-throw guarantee: Very difficult or impossible to implement, since memory allocation may fail and throw an exception. Handling allocation failure would then be problematic, since repeated attempts are also likely to fail.
• Strong exception safety: Can be implemented fairly easily by doing any allocation and copying into a temporary buffer that is swapped if no errors are encountered. In this case, insertion of x into v will either succeed, or v will remain unchanged.
• Basic exception safety: Implemented by ensuring that the size field is guaranteed to be updated if x is successfully inserted. Also, all allocations needs to be handled in a way that prevents any chance of a memory leak, regardless of failure.
• No exception safety: Implementation where an insertion failure might lead to corrupted content in v, inconsistent size field, or a memory leak.

References

External references

• Jon Kalb: Exception-Safe Coding in C++, with C++Now! 2012 presentations on exception safety.
• Related discussion on Stackoverflow: C++: do you (really) write exception safe code