From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-04-12 13:43:27
At 11:17 AM 4/12/2001, David Abrahams wrote:
>----- Original Message -----
>From: "Beman Dawes" <bdawes_at_[hidden]>
>> At 07:03 PM 4/11/2001, David Abrahams wrote:
>> >... discussion and reference to "Errors and Exception Handling" paper
>> Dave, if I've followed you correctly, you are arguing that:
>> * "invariants and postconditions should be asserted"
>> * precondition assertions are desirable, but not always possible, and
>> a QOI issue.
>I don't think I said that.
I was trying to reduce several paragraphs in several postings to an
understandable policy. Let's try again:
* Invariants and postconditions should be asserted.
* Preconditions should be asserted. If it's not possible to assert the
condition inside the called function, it isn't possible to check it
outside, and thus it shouldn't be a precondition.
* Exceptions should only be thrown if all of the following criteria are
- The condition can't easily be checked or ensured by the caller.
For example, resource allocation failures or input file
- Stack unwinding would be desirable.
- Stack unwinding would be affordable.
[Should there be a fourth condition to the effect that the condition
wouldn't be reasonable to handle by returning an error indication?]
>> If so, what do you think of Bill Kempf's suggestion of a BOOST_ASSERT()
>> which asserted in debug mode, and is user configurable in release mode
>> throw or not?
>I think there's insufficient granularity. Peter Dimov's
>boost_precondition_check suggestion is better. Ideally it should be
>to handle precondition checking differently from postcondition and
>checking. I would just assert for postconditions and invariants.
Did you mean Peter's boost::precondition_violation() idea from a few
messages back? Could someone explain in a bit more detail how that would
>> Wouldn't that put error handling on a lot firmer ground that the
>I don't know if it buys us any certainty to allow configurable behavior
>precondition checks ;-)
I'm not trying to push you into something you don't believe in. But I am
trying to see if there is a clear error handling policy we can agree on and
maybe even reduce to Scott Meyers-like rules which can be applied by a
moderately skilled Boost programmer. Also to see if we should be trying to
develop boost::precondition_violation, BOOST_ASSERT, or whatnot.
>> (I know that implies debug/throw/nothrow library builds (rather than
>> debug/release) but let's assume we are willing to pay that cost.)
>Oof. I am still reluctant to add throwing behavior for precondition
>though people seem to want it. Part of the problem is that many implicit
>preconditions will probably go unchecked (e.g. is someone calling a
>function through an invalid pointer). Providing a truly bulletproof
>interface is expensive. I don't think most library designers will do it,
>and many that try will probably take half-measures.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk