assert vs. enforce in Phobos code
monarch_dodra
monarchdodra at gmail.com
Sun Feb 23 08:10:02 PST 2014
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.
More information about the Digitalmars-d
mailing list