[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 10:54:40

Pavol Droba <droba_at_[hidden]> writes:

> On Thu, Jul 15, 2004 at 07:03:38AM -0400, David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>> 
>> > Such a guarantee would allow me to use a local variable of a given type
>> > without needing to worry, that it will break the guarantie of the whole
>> > function.
>> >
>> > Is this ok? 
>> >
>> > How would you name such a property? 
>> 
>> While I support the use of the "pure" distinction in exception-safety
>> analysis, a word of caution: be careful not to specify such a detailed
>> ES contract that it becomes unreasonably hard to use.  Another risk is
>> that you'll undly constrain your future implementation choices.
>> Sometimes it makes sense to paint with a slightly broader brush and
>> and provide a simpler guarantee.
>> 
>> Further, I'm not sure it usually makes sense to use "pure" when
>> describing constraints on user-supplied operations.  It stands to
>> reason that in general, the library has no knowledge of external state
>> that might be modified by a user-supplied operation and can't roll
>> back the results.  It's often a reasonable shorthand to say "gives the
>> strong guarantee" when you mean "gives the strong guarantee as long
>> as the user-supplied operation is pure".
>> 
>
> I have written sumarized something. Is this correct:
>
> "
> Exception Safety
>
> The library requires that all operations on types used as template
> or function arguments provide the basic exception guarantee. 
> In turn, all functions and algorithms in this library, except where stated
> otherwise, will provide the basic exceptions guarantee.

I hope not.  There should be no instance in which you don't provide
the basic guarantee.

Fundamentally you don't have to say any of what's in that paragraph,
though I don't mind it in principle.  By definition, you *can't* break
invariants.  Unless you explicitly say you're going to leak resources,
the client has a right to expect you won't, even in the face of
exceptions.  Nothing gives the client license to break imposed
requirements, even in the face of exceptions.

> In addtion some functions can provide the strong exception guarantee
> as long as the operations on the types used for arguments for these
> funtions either do not alter the global state, or provide the strong
> exception guarantee.

Probably an English usage error, but that means that if operations on
the arguments to functions provide the strong guarantee, the functions
won't provide it.

I would either throw out this whole thing or rewrite it as follows:

  The library maintains its invariants and does not leak resources in
  the face of exceptions.  Some library operations give stronger
  guarantees, which are documented on an individual basis.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com