TITLE: what is exception safety


PROBLEM: 100653.2230@compuserve.com (Raoul De Kezel)

Could somebody give a precise definition of "exception-safe" ?


RESPONSE: kanze@gabi-soft.fr (J. Kanze), 9 Apr 96

There isn't a precise definition.  A lot depends on what you are using
exceptions for.  With regards to your (deleted) comments, however:

Exception safety generally refers to the code through which an exception
passes, and not the code which contains the throw or the catch.  It is
concerned with the data consistency, of which resource allocation is the
most often cited example, when the code is interrupted due to an
exception.

There are different degrees of exception safety: at the very least, all
objects must be left in a state in which they can be destructed.
According to the application, one might also require that the object be
able to be further used, or even that its value be as if the interrupted
action never started.  In all cases, it is desired that all resources
associated with the object are freed, although in the first case, this
could be a result of the final destruction.

With regards to your example concerning swap:

1. When making a function exception safe, you *must* start from the
point of view that all of the called functions are already exception
safe.  Otherwise, the problem is impossible.  In the case of swap, this
means that the copy constructor and assignment operator meet at least
the conditions (the degree of exception safety) that we are trying to
attain.

2. Since swap has no permenant internal state, it is implicitly
exception safe with regards to being destructable.  On the other hand,
it is easy to conceive of classes which use swap, and require the swap
function to be `atomic with regards to exceptions', in order for them to
even meet the weakest condition (destructable, with all resources freed
after destruction).

If we suppose that operator= either succeeds or fails, and that if it
fails, the preceding state is restored, then the following version of
swap is partially exception safe (I think):

	template< class T >
	void
	swap( T& a , T& b )
	{
		T				tmp( a ) ;		//	1.
		a = b ;							//	2.
		try
		{
			b = tmp ;					//	3.
		}
		catch ( ... )
		{
			a = tmp ;					//	4.
			throw ;
		}
	}

Exceptions can only occur at each of the numbered lines.  Consider the
consequences of each case separately:

1. No problem.  We've not changed any non-local values yet.

2. No problem, since operator= should leave a in the correct state.

3. Operator= should leave b in the correct state, and we restore a in
the catch block.

4. There's not much one can do here.  An uncaught exception here will
result in the function `terminate' being called, but I hardly see what
you can do if you decide to catch the exception.

Just out of curiosity, what do those of you who use exceptions do in
this case?

Note that the case is actually very rare.  In most of the examples I
can think of where swap must be able to undo its actions, the data type
being swapped is a pointer, and neither the copy constructor nor the
assignment operator of a pointer can ever throw an exception.  This will
also be true of most smart pointers (reference counting, etc.), at least
if you impose the rule that an exception cannot escape out of a
destructor.  (An essential rule, IMHO.)  On the other hand, if your
smart pointers are actually handles to data on disk, and something
happens to the disk between statement 2 and statement 3, I think you've
lost data, with or without exceptions.  I presume that your design is
capable of handling this case.