against enforce
Don
nospam at nospam.com
Sat Mar 26 08:55:53 PDT 2011
spir wrote:
> On 03/25/2011 11:20 PM, Jonathan M Davis wrote:
>> In the case of something like dividing by 0 or other math functions
>> that could
>> be given bad values, the typical solution is to either use an
>> assertion (or
>> check nothing) and then let the caller worry about it. It would be
>> extremely
>> wasteful to have to constantly check whether the arguments to typical
>> math
>> functions are valid. They almost always are, and those types of functions
>> needto be really efficient.
>
> But catching wrong arguments to math functions at *runtime* is precisely
> what D itself does (as well as all languages I know):
>
> auto a = 1, b = 0;
> auto c = a/b;
> ==>
> Floating point exception
>
> There is no way out, or do I miss a point?
>
> Denis
That one is done by the CPU, as mentioned in another post. But it does
illustrate something interesting: the contract programming makes you
think there is a symmetry between in and out contracts, whereas in fact
they have very little in common. If an out contract fails, it ALWAYS
indicates a bug in the function. So it should ALWAYS be an assert.
But 'in' contracts are completely different, since they indicate a
problem in the calling code. (Personally I cannot see the value of 'out'
contracts, except as information for verifying later 'in' contracts).
When I started writing D code, I originally used 'in' contracts
frequently in my mathematical code. But later, I removed most of them.
Why? Because including a particular condition in a 'in' contract makes
it undefined behaviour in release mode!
So you need to be clear, is this parameter value a runtime error, or is
it a bug in the calling code?
In most mathematical code, you want it to be an error -- you don't
normally want undefined behaviour for particular inputs. If the
requirements for valid parameter values are complicated, you're placing
a huge burden on the caller if you include asserts, making them bugs.
In summary: enforce is nice for the caller, assert is nice for the callee.
The decision of whom to favour can be tricky.
More information about the Digitalmars-d
mailing list