Exception Guarantee

In http://www.stlport.org/doc/exception_safety.html, DaveAbrahams? proposes three levels of exception guarantees for the StlPort library:

Since the publication of this note in 1996, others in the C++ community (most notably HerbSutter, in several of his books and articles) refined the concept to the following:

Note that these guarantees form a hierarchy: each higher guarantee adds additional requirements to the lower guarantees. The requirements of the Nofail guarantee are a strict superset of the Strong guarantee because the final observable state will always be the intended target state, and the requirements of the Strong guarantee are a strict superset of the Basic guarantee because either the original state or the intended target state are valid states.

The Basic guarantee is required for every function in a program--anything less than the basic guarantee is a defect.

Implementing these guarantees creates a number of beneficial side effects. For one, responsibility for establishing a function's preconditions is firmly placed on the caller of the function. No exceptions should be thrown from a function for precondition violations; instead, these can be viewed as programming defects (not run-time errors), and can be handled via other mechanisms (like assertions).

Another side effect is that it helps expose potential ExtractMethod refactorings: when a function can make a stronger guarantee for part of its work than for another part, it's time to split that function.

The ExceptionGuarantee paradigm hinges on a number of other paradigms: If your software development method doesn't match up with these paradigms, it's often difficult to apply the ExceptionGuarantee paradigm (for example, idiomatic CeeLanguage, PythonLanguage, PerlLanguage, and SmallTalk don't seem to match up well).

The error case of "a function can not achieve its own preconditions" is somewhat slippery. This usually should be covered in the caller's definition of an error, and in earlier embodiments of ExceptionGuarantees, this was the case. However, occasionally a function can have preconditions that can't easily be detected or checked by its caller, so this "escape hatch" was granted for only those cases.

Personally, I don't like the introduction of this loophole. It's a CodeSmell that seems to ask for ExtractMethod. --TimLesher

Note that asserting (terminating the program) is not considered to violate the exception guarantees--even though the program comes to a grinding halt. Asserting is done (in the StlPort context above) as a diagnostic for incorrect use of a library (failure to satisfy preconditions that can be detected by a caller), not as a diagnostic for defects discovered within a library.

View edit of November 18, 2004 or FindPage with title or text search