Jonathan M Davis wrote:
On 2011-03-26 08:55, 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).
Whereas I _rarely_ use in contracts. In most cases, I favor exceptions,
treating my functions as API functions pretty much as long as they're public.
That's not always the best approach, but it's generally what I end up using.
invariants, I use fairly frequently (and in fact have run into trouble due to
issues with them - e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5058 ).
out, on the other hand, I don't use as much. It's not terribly common that
there's a good test to run on the return value of a function in my experience.
Upon occasion, it's useful, but rarely. Unit tests generally solve the problem
better with regards to testing output. They're still useful though - just not
commonly so.
So, honestly, other than invariants, I don't use D's DbC much. in contracts
get used upon occasion, but I tend to favor exceptions over assertions in most
cases, so I don't use in all that often, and while out is occasionally useful,
unit tests generally do a better job of verifying that a function's return
value is correct. I'm _very_ glad to have invariants though.
- Jonathan M Davis
If you only have standalone functions, at the moment there's not really
any benefit to in and out contracts. You can equally well put the
asserts at the start and end of the function.
I totally agree with you about invariants. I've been amazed at how many
bugs can be caught by even a very trivial invariant.
