Program logic bugs vs input/environmental errors

[w0rp via Digitalmars-d]

On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>> On 2014-10-18 07:09, Walter Bright wrote:
>>
>>> Which means they'll be program bugs, not environmental errors.
>>
>> Yes, but just because I made a mistake in using a function 
>> (hitting an assert)
>> doesn't mean I want to have undefined behavior.
>
>
> As I've said before, tripping an assert by definition means the 
> program has entered an unknown state. I don't believe it is 
> possible for any language to make guarantees beyond that point.
>
> Now, if it is a "known" unknown state, and you want to recover, 
> the solution is straightforward - use enforce(). enforce() 
> offers the guarantees you're asking for.
>
> Using assert() when you mean enforce() is like pulling the fire 
> alarm but not wanting the fire dept. to show up.

I agree with you on this. I've only ever used assert() for 
expressing, "This should never happen." There's a difference 
between "this might happen if the environment goes wrong," which 
is like a tire being popped in car, and "this should never 
happen," which is like a car turning into King Kong and flying 
away. My most common assert in D is typically assert(x !is null) 
for demanding that objects are initialised.