On Sunday, 23 February 2014 at 09:55:29 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
This is a subject I think we've visited before, but I can't
find the old discussion threads :-(
As some of you know I'm working on a successor to std.random --
it's been put on hold the last 8 weeks or so by
country/life/work changes, but now I'm back onto it. One of
the things I'm examining in the course of that is the error
checking.
For example, a call to uniform(a, b) sees the function ensure
that the interval is appropriate via an enforce(a <= b). The
result is that passing the wrong values to uniform() will bring
your program down. There are many other comparable cases in
the module.
Part of me feels this is absolutely right and that such errors
should be strictly objected to in this way. On the other hand,
this seems a wrong approach given that these kinds of functions
are surely going to be called deep within the program -- we're
not verifying user input here, it would be a logical error in
the program to pass wrong bounds to uniform() and so on.
My inclination is to clean this stuff up, to generally replace
enforce's with asserts, to provide in- and out-contracts where
appropriate, and so on.
Thoughts, remarks, ... ?
Thanks & best wishes,
-- Joe
As a rule of thumb, "enforce" is not necessarily for things
"user-input" but for things "outside the programmer's control"
eg: "things that can legitimately fail", Notably, IO, threads,
databases etc...
If you see any phobos code that validates the range of its inputs
via an enforce, please knock yourself out and assert it/contract
it.
