Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-04-13 08:44:29

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 07:03 PM 4/11/2001, David Abrahams wrote:
> >... discussion and reference to "Errors and Exception Handling"
> 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 thus
> a QOI issue.
> * For release builds, you also favor throwing an exception for all
> cases (with the precondition QOI caveat), but only if both the
> 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?
> If so, what do you think of Bill Kempf's suggestion of a
> which asserted in debug mode, and is user configurable in release
mode to
> throw or not?
> Wouldn't that put error handling on a lot firmer ground that the
> uncertainty?
> (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.)

This debate has already sparked me into developing such a library.
I'm modelling the on/off functionality closer to the Eiffel approach
where each assertion type (pre/post condition, invariant and check)
belongs to a level and the programmer sets the level of assertion
support at compile time. There are a *LOT* of issues that need to be
addressed (ODR, static initialization errors, etc.) but I'll post a
beginning either today or Monday that may be a good starting place
for discussion.

Bill Kempf

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