On 03/26/2011 04:55 PM, Don wrote:
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.
Very interesting points of view, than you! Especially
* making the misleading symmetry between 'in' & 'out' contracts (==> importance
of *naming*, again!)
* the relative weakness of in contracts or asserts.
About 'out' contracts, I know see them as an alternate way of testing, during
development or maintenance. Kinds of constant assertions (in the logical sense)
checked there, which may help catching bugs, and before all do not need to be
checked in unittests.
Denis
--
_________________
vita es estrany
spir.wikidot.com
