[boost] Re: any_function (callback) library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-11 19:06:15

>  > Not really. In one place out of the thousands(?) of preconditions
>in
>>  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 
legitimate reasons...

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

Yep.

   -- Jesse