Exception safety

Exception safety guarantees, originally formalized by David Abrahams,[1][2] are a set of contractual guidelines that class library implementers and clients can use when reasoning about exception handling safety in any programming language that uses exceptions, particularly C++.

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 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 retains their original values.[4]
  3. Basic exception safety, also known as a no-leak guarantee: Partial execution of failed operations can cause side effects, but all invariants are preserved and there are no resource leaks (including memory leaks). Any stored data will contain valid values, even if they differ from what they were before the exception.
  4. No exception safety: No guarantees are made.

Usually, at least basic exception safety is required to write robust code in such languages. 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 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
Impossible to implement - you never can guarantee that your resources (memory/disk space) are sufficient.
Strong exception safety
Can be implemented fairly easily by doing any allocation first and then copying into a temporary buffer that is eventually 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 need to be handled in a way that prevents any chance of a resource leak, regardless of failure.
No exception safety
Implementation in which an insertion failure might lead to corrupted content in v , an incorrect size value, or a resource leak.

References

  1. ↑ "Exception-Safety in Generic Components". Retrieved 2008-08-29.
  2. ↑ Abrahams, D. (2000). Exception-Safety in Generic Components. Generic Programming. LNCS. 1766. Springer. pp. 69–79. doi:10.1007/3-540-39953-4_6. ISBN 978-3-540-41090-4.
  3. ↑ Bjarne Stroustrup. "Appendix E: Standard-Library Exception Safety in "The C++ Programming Language" (3rd Edition).Addison-Wesley," (PDF). ISBN 0-201-88954-4.
  4. ↑ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1077.asc
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.