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

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-12 10:17:31

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

You may be confused by the way I referred to resource allocation issues. In
some sense, having enough memory to complete the function would be a
precondition, but it isn't practical (or even possible, sometimes) for the
caller to check it. So instead, we don't make it a precondition of the
function and instead promise to throw if memory runs out.

So I think precondition assertions are pretty much always possible... if
it's not possible to assert the condition inside the called function, it
isn't possible to check it outside, and thus we should not make it a
precondition.

> * For release builds, you also favor throwing an exception for all three
> cases (with the precondition QOI caveat)

No, I only favor throwing exceptions for cases which can't be easily checked
or ensured by the caller, like resource allocation failures or input file
format errors.

> but only if both the following criteria are true:
>     - Do we want stack unwinding here?
>
>     - Can we afford stack unwinding here?
>
> Am I wrong in thinking that the user of a library rather than the
> implementor is often the best person to answer those questions?

It certainly seems from the way I've phrased things like that would be the
case, but I never meant to imply that and in practice I think the library
implementor can usually make the determination. Maybe when you include the
criterion of checkability by the caller it tilts the balance in the other
direction.

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

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

-Dave