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