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
