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"
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 thus
> a QOI issue.
>
> * For release builds, you also favor throwing an exception for all
three
> cases (with the precondition QOI caveat), 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?
>
> 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?
>
> Wouldn't that put error handling on a lot firmer ground that the
current
> 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