Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at