Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 9/28/2014 1:50 PM, Sean Kelly wrote:
> On Sunday, 28 September 2014 at 20:31:03 UTC, Walter Bright wrote:
>> > The scope of a logic bug can be known to be quite limited.
>>
>> If you know about the bug, then you'd have fixed it already instead of
>> inserting recovery code for unknown problems. I can't really accept that one
>> has "unknown bugs of known scope".
>
> Well, say you're using SafeD or some other system where you know that memory
> corruption is not possible (pure functional programming, for example).  In this
> case, if you know what data a particular execution flow touches, you know the
> scope of the potential damage.  And if the data touched is all either shared but
> read-only or generated during the processing of the request, you can be
> reasonably certain that nothing outside the scope of the transaction has been
> adversely affected at all.

You may know the error is not a memory corrupting one, but that doesn't mean 
there aren't non-corrupting changes to the shared memory that would result in 
additional unexpected failures. Also, the logic bug may be the result of an 
@system part of the code going wrong. You do not know, because YOU DO NOT KNOW 
the cause the error. And if you knew the cause, you wouldn't need a stack trace 
to debug it anyway.

I.e. despite being 'safe' it does not imply the program is in a predictable or 
anticipated state.

I can't get behind the notion of "reasonably certain". I certainly would not use 
such techniques in any code that needs to be robust, and we should not be using 
such cowboy techniques in Phobos nor officially advocate their use.