I have been working on a research code with a colleague. In a
comment, I explained why I complicated one part of the code in order
to preserve the strong exception guarantee. This is a C++ way of
saying "transactional semantics": either the operation succeeds, or it
commits no side effects. I remarked that preserving the strong
exception guarantee whenever possible is a kata -- practice of a form
that teaches through repetition. This reminded me of the three stages of mastery:http://en.wikipedia.org/wiki/Shu_Ha_Ri
There are certainly reasons to "digress" (Ha) from the strong
exception guarantee. One's software may be modeling or interfacing
with a physical system, where side effects commonly accompany (or
cause) failure to perform to specification. (Light bulbs that don't
turn on probably have a burnt-out filament.) Keeping the strong
exception guarantee also costs resources, such as temporary copies of input arguments. Scientific computing tends to push resource
requirements, or at least has done so historically. Thus, coders
working in this paradigm tend to favor conserving resources, like
memory and operations, at the expense of other guarantees.
The strong exception guarantee is a special case of an "invariant" --
a property of the program that does not change when a particular
routine runs. I remember invariants as a tedious ritual of my
freshman introduction to programming course, rather like "showing
one's work" in algebra. Both felt like "repeating the self-evident."
Successive programming courses dropped invariants without comment. I wonder now whether continuous practice and respect for the "invariants kata" would have simplified some tricky data structures work later on. I wonder also if language support for declaring and checking invariants in my freshman course (we slogged our way through Java, which "dragged C programmers halfway to COBOL") would have made me appreciate their value sooner.