On Tuesday, 4 August 2015 at 22:06:06 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 4 August 2015 at 20:21:24 UTC, Walter Bright wrote:
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com> wrote:
The input/environment/code distinction does not work very
well.
Sure it does. If your user ever sees an assert failure
message, your program has a bug in it.
Yes.
Keep that in mind when designing the code, and the distinction
will become clear.
The input/code distinction is too simplistic.
Example 1: It makes perfect sense to assert (or assume) that a
value from a hardware register or cpu instruction is within
range. If the assert fires, it is the spec/code that is wrong,
not the input. So you are testing the specification in the code
against well defined input.
Example 2: It makes perfect sense to enforce that a return
value from a plugin library is within range to maintain main
program integrity and shut out a misbehaving plugin.
And so on.
I'm 90% on Walter's side here as he's right for the majority of
common cases, but on the other hand there are plenty of
situations where the boundary between code error and environment
error get blurred.
