Boost logo

Boost :

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
> 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
> with the possible exception that the default handler may do
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at