Re: any_function (callback) library

From: williamkempf_at_[hidden]
Date: 2001-04-13 09:02:34

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "David Abrahams" <abrahams_at_m...>
> 
> > Oof. I am still reluctant to add throwing behavior for 
precondition
> checks,
> > though people seem to want it.
> 
> Rightly so, since by definition, if a function is documented to 
throw if X,
> then X is not a precondition.

Tell that to Bertrand Meyers, creator of Eiffel and father of DbC.  
The results of failing to fullfill the client contract (the 
preconditions) are undefined, but when checking is on the result must 
be a known exception.  There are reasons for this, including the need 
for some software to be able to catch such errors at runtime to 
insure a hard crash does not occur.

> The user should probably be able to make precondition_violation 
throw by
> overriding it (set_precondition_handler?), but throwing shouldn't 
be one of
> the 'standard' behaviors of precondition_violation.
> 
> The options for the documented interface of a function, as I see 
them, are:
> 
> [1] f() throws if X;
> [2] f() calls precondition_violation if X;
> [3] the behavior of f() is undefined if X.
> 
> Having precondition_violation won't make the question of choosing 
among the
> three magically go away, however. :-)

No, but it gives a more rigorous mechanism for dealing with errors, 
making the decision much easier to deal with in many cases.
 
> Note that I think that [2] should work the same in debug or release 
builds,
> with the possible exception that the default handler may do 
different
> things. The check should not disappear.

Then the check *MUST* throw an exception.  A hard halt in a realease 
build is hardly ever going to be the appropriate action.  However, 
once again Bertrand Meyers doesn't agree with you here, and he 
provides compelling arguments.

Bill Kempf