Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-04-13 09:24:26

From: <williamkempf_at_[hidden]>

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

I don't necessarily disagree with Bertrand Meyers here.

unsigned f(unsigned i);

// preconditions: none
// effects: throws X when i is odd, returns i / 2 when i is even

unsigned g(unsigned i);

// preconditions: i must be even
// effects: returns i / 2

The difference is that you can depend on f's behavior when i is odd, but you
must not depend on g's behavior when i is odd (in correct code).

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

You are trying to second-guess the user.

A hard halt that saves a stack trace, prepares a bug report and copies it to
the clipboard is very likely to be useful. Remember that when you throw an
exception you lose the context.

Bertrand Meyers fans still have the option to throw whatever exception they
like from precondition_violation.

Peter Dimov
Multi Media Ltd.

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