Re: [boost] Re: any_function (callback) library

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-12 18:52:09

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
>
> I was trying to reduce several paragraphs in several postings to an
> understandable policy.

Noble!

> 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
> met:
>      - The condition can't easily be checked or ensured by the caller.
>        For example, resource allocation failures or input file
>        format errors.
>      - Stack unwinding would be desirable.
>      - Stack unwinding would be affordable.

Good so far!

> [Should there be a fourth condition to the effect that the condition
> wouldn't be reasonable to handle by returning an error indication?]

Instead, add:

     OR if both of the following are true:
      - The condition can't easily be checked or ensured by the caller.
        For example, resource allocation failures or input file
        format errors.
      - There is no other reasonable mechanism for reporting the error
        (e.g. from constructors)

>  >> 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
> to
>  >> throw or not?
>  >
>  >I think there's insufficient granularity. Peter Dimov's
>  >boost_precondition_check suggestion is better. Ideally it should be
>  >possible
>  >to handle precondition checking differently from postcondition and
>  >invariant
>  >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
> work?

Something just like Bill's suggestion, only it is used just for
preconditions.

>  >> Wouldn't that put error handling on a lot firmer ground that the
> current
>  >> uncertainty?
>  >
>  >I don't know if it buys us any certainty to allow configurable behavior
> for
>  >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.

Let's put it this way: I don't neccessarily believe in it, but I'm willing
(if pressed) to accept that people who DO believe in it know what they're
talking about; that some applications really need it. So accepting
boost::precondition_violation is a way of reflecting a (possibly) emerging
consensus.

-Dave