[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-17 07:03:01

"David B. Held" <dheld_at_[hidden]> writes:

> David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>>[...]
>>>"
>>>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.
>
> The idea is that the library may offer some other guarantee instead
> of the basic guarantee.

No, you can strengthen the guarantee -- in other words, offer some
guarantees in addition to the basic guarantee -- but unless the
library is going to take an "invariants don't matter because I'm about
to terminate" strategy, you must always give 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.
>
> Well, considering that many programmers don't even know how to talk
> about exception safety, I don't think it hurts to have a reminder
> that if the library behaves in an exception-unsafe way, it's the
> user's fault.

I agree that a reminder is good, but don't agree with "if the library
behaves in an exception-unsafe way", because it's not the library
that's misbehaving.

>> [...]
>> 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.
>
> Ah, but you yourself have said that the guarantees do not form a
> hierarchy, so there is no proper notion of "stronger" with respect to
> them. ;)  

Whaaaa???  I never said that!  Or I was delusional when I did.

> Pretty easy to say it that way though, huh?  Anyway, I would
> say that many libraries do *not* offer the basic guarantee, and that
> the value in saying so is that it indicates the author has considered
> the issue and certifies that the library is minimally
> exception-safe.

Yes, but if the reader doesn't know the meaning of the term, it will
not help her.  It's such a simple concept that it doesn't hurt to
spell it out.

> Saying that it maintains its invariants instead of saying that it
> gives the basic guarantee does not convey the right message, in my
> opinion, because many programmers obviously do not feel a need to
> maintain invariants in the presence of exceptions (or they would write
> more exception-safe code).

I don't see the connection.  What message do you think it should send
that it does not send?

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