From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-11 19:06:15
> > Not really. In one place out of the thousands(?) of preconditions
>> the standard they provided an alternate API that throws. All this
> > means is that committee was unwilling to use exceptions for
>> precondition violations except in one special case.
>The problem I have is why is there "one special case"? It's
>decisions like this that make it impossible to know when to use
>exceptions and when not to.
The standard library doesn't have a strategy for handling this sort
of thing. It's strictly a QOI issue. That's why there is this weird
aberration. The committee seems to have decided that vector indexing
was important enough that they would provide a checked version for
people who absolutely needed checks. Boost is different: we're
defining the interfaces *and* providing a reference implementation.
>Eiffel has a minimal "global policy for failures". Basically, you
>can turn assertions on or off (with varying levels according to
>whether they're preconditions, postconditions or invariants). You
>can't redefine what occurs when assertions fail to, for instance,
>halt the program immediately or to log the error to a file.
Sure, but if we provided something like this in boost we'd want to
allow for all of this.
>More importantly, since these *ARE* exceptions you can catch them and
>continue program execution. C/C++ asserts do not behave this way at
>all. So you aren't really in favor of assertions here, but rather in
>a configurable mechanism that will throw an exception when the policy
>is turned on. Dave, on the other hand, doesn't like exceptions
>because they unwind the stack making debugging difficult.
But he's open to the possibility that people will want exceptions for
>It seems to me that there are 3 types of errors that one needs to
>decide how to handle:
>1) Expected errors, such as a search that fails to find anything.
>2) Unexpected errors, such as trying to allocate memory when there's
>3) Violation of pre/post-conditions and invariants.
>Most people will agree that (1) warrants an error return code while
>(2) warrants an exception (though it's often hard to tell the
>difference between (2) and (3) for some errors). It's (3) that's got
>everyone up in arms. Most people would agree you need to be able to
>shut these sorts of checks off for release builds, though it seems
>valid to leave them on even for release builds under certain
>circumstances (and those may not be on an app wide case, making this
>harder to deal with). However, when on should they halt the program
>(assert) or throw an exception?
They should be customizable. This will keep the performance freaks
happy (including the ones who really do need every bit of speed they
can squeeze out), it will allow people to use custom asserts so that
they're dropped into the debugger instead of simply exiting, and it
will allow exceptions for those who want to attempt to recover.
>If Boost really wants to do the "best thing" here I think we need
>written guidelines and a BOOST_ASSERT(?) for case (3). With out both
>of these every time this argument comes up I'd expect us to rehash
>everything again and again with no real resolution to the topic.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk