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

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"
 >
 >Yes.
 >
 >> * precondition assertions are desirable, but not always possible, and
 >thus
 >> 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 
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.

[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 
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?

 >> 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.

 >> (I know that implies debug/throw/nothrow library builds (rather than 
just
 >> debug/release) but let's assume we are willing to pay that cost.)
 >
 >Oof. I am still reluctant to add throwing behavior for precondition 
checks,
 >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 
member
 >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.

Understood.

--Beman