Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 10/17/2014 9:13 AM, Jacob Carlborg wrote:
> On 2014-10-16 21:31, Walter Bright wrote:
>
>> Contract errors in Phobos/Druntime should be limited to having passed it
>> invalid arguments, which should be documented
>
> That doesn't mean it won't happen.

Which means they'll be program bugs, not environmental errors.

It is of great value to distinguish between program bugs and input/environmental 
errors, and to treat them entirely differently. It makes code easier to 
understand, more robust, and better/faster code can be generated.

Using asserts to detect input/environmental errors is a bad practice - something 
like enforce() should be used instead.

I understand that some have to work with poorly written libraries that 
incorrectly use assert. If that's the only issue with those libraries, you're 
probably lucky :-) Short term, I suggest editing the code of those libraries, 
and pressuring the authors of them. Longer term, we need to establish a culture 
of using assert/enforce correctly.

This is not as pie-in-the-sky as it sounds. Over the years, a lot of formerly 
popular bad practices in C and C++ have been relentlessly driven out of 
existence by getting the influential members of the communities to endorse and 
advocate proper best practices.

----------------------

I do my best to practice what I preach. In the DMD source code, an assert 
tripping always, by definition, means it's a compiler bug. It is never used to 
signal errors in code being compiled or environmental errors. If a badly formed 
.d file causes dmd to assert, it is always a BUG in dmd.