[boost] Re: any_function (callback) library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-11 17:52:14

At 1:41 PM +0000 4/11/01, williamkempf_at_[hidden] wrote:
>--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
>  > >  > 6) Trying to invoke an empty function seems like a precondition
>>  >>  violation to me. Asserting instead of throwing seems preferable.
>>  >
>>  >I disagree because using an assertion means that the check might
>be turned
>>  >off. If that happens, any_function will cause a segmentation
>violation. At
>>  >least throwing an exception gives some form of recovery.
>>
>>  Would you also throw if someone passed a nil char* into
>std::string's
>>  ctor? Indexed past the end of a std::array? Passed bogus iterators
>>  into std::find? Personally I don't think any of these should throw:
>>  they should assert whenever possible and follow the normal code
>path
>>  thereafter. This is *exactly* what asserts are for.
>
>Indexing past the end of std::array does throw, at least when you use
>at() instead of [].  This kind of throws your whole argument here
>out.

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.

>I'm really learning to hate exceptions.  _NO ONE_ agrees on
>when they should be used.  Even people who think they have their own
>set of rules for when to use them seem to violate the rules
>themselves from what I've seen.

Yeah, but it's important to talk about this stuff. Design by 
Contract, for example, has a lot of merit, but vendors have as a rule 
done a terrible job providing debugging support in their libraries. 
I'd like to think that boost could do better.

>As for the argument that asserts should be used instead... an assert
>is a C concept that existed before exceptions.  In fact, other
>languages throw exceptions on failed assertions to further cloud this
>argument.  Saying that this is exactly what assertions are for does
>not help to argue your case, or to help people like me figure out
>when to use what kind of error handling.

The only language that I know about that handles this stuff well is 
Eiffel. There you have language support for preconditions, 
postconditions, and invariants. By default failures throw, but you 
can turn off all the checks in release if you desire. This is 
*exactly* what I want: rigorous checking of preconditions and 
postconditions coupled with a global policy to control the behavior 
of failures. Of course we're not there yet, but it would be great if 
people would begin to think in this way when they implement classes.

   -- Jesse