Against enforce()

spir denis.spir at gmail.com
Fri Mar 18 08:35:22 PDT 2011


On 03/18/2011 01:37 PM, Steven Schveighoffer wrote:
> This is a good example of why it's difficult to decide what "user input" is.
> One could consider that the 'user' in this case is the developer using the
> library, but I don't think that's the right choice.
>
> I'd say it's a bug, this is clearly a contract, since the data being passed
> into the ctor can easily not be user input (i.e. it's most likely two literals
> that will never depend on a user).  If it is user input, the caller of the ctor
> should enforce the user input before passing it to iota.

This is indeed a difficult topic. I'm a bit bluffed when reading people 
confidently asserting apparently clear positions about the use of enforce vs 
assert vs contracts and such, or whether such checks should or not stay or not 
in various distribution builds (mainly -release).
I can see at least 5 cases, and am far to be sure what the proper tool is in 
every case, and in which builds it should stay. In each case, there is 
potential "wrong" input; but note the variety of cases does seems orthogonal 
(lol) to what kind of harm it may cause:

* colleague: my code is called by code from the same app (same dev team); 
typically, wrong input logically "cannot" happen
* friend: my code is called by code designed to cooperate with it; there is a 
kind of moral contract
In both cases, wrong input reveals a bug; but in the first case, it's my own 
(team's) bug. I guess, but am not sure, these cases are good candidates for 
asserts (or contracts?), excluded from release build.

* lib call: my code is a typical lib; thus, I have zero control on caller.
I would let the check in release mode, thus use enforce. Or, use assert if it 
remains when the *caller* is compiled in debug mode. There is something unclear 
here, I guess. Maybe there are two sub-cases:
	~ the caller logically should be able to prove its args correct
	~ or not
In the first case, checks should dispappear in release mode. But there is 
always a risk. So, what to choose if my func really requires correct input?
By the way, I don't understand the diff between enforce and alwaysAssert; I 
thought enforce was precisely an alwaysAssert.

* user input: cope with it.
It's the only clear case for me.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d mailing list