Program logic bugs vs input/environmental errors

[Sean Kelly via Digitalmars-d]

On Monday, 29 September 2014 at 00:09:59 UTC, Walter Bright wrote:
> On 9/28/2014 3:51 PM, Joseph Rushton Wakeling via Digitalmars-d 
> wrote:
>> However, it's clearly very desirable in this use-case for the 
>> application to
>> keep going if at all possible and for any problem, even an 
>> Error, to be
>> contained in its local context if we can do so.  (By "local 
>> context", in
>> practice this probably means a thread or fiber or some other 
>> similar programming
>> construct.)
>
> If the program has entered an unknown state, its behavior from 
> then on cannot be predictable. There's nothing I or D can do 
> about that. D cannot officially endorse such a practice, though 
> D being a systems programming language it will let you do what 
> you want.
>
> I would not even consider such a practice for a program that is 
> in charge of anything that could result in injury, death, 
> property damage, security breaches, etc.

Well... suppose you design a system with redundancy such that an 
error in a specific process isn't enough to bring down the 
system.  Say it's a quorum method or whatever.  In the instance 
that a process goes crazy, I would argue that the system is in an 
undefined state but a state that it's designed specifically to 
handle, even if that state can't be explicitly defined at design 
time.  Now if enough things go wrong at once the whole system 
will still fail, but it's about building systems with the 
expectation that errors will occur.  They may even be logic 
errors--I think it's kind of irrelevant at that point.

Even a network of communicating processes, one getting in a bad 
state can theoretically poison the entire system and you're often 
not in a position to simply shut down the whole thing and wait 
for a repairman.  And simply rebooting the system if it's a bad 
sensor that's causing the problem just means a pause before 
another failure cascade.  I think any modern program designed to 
run continuously (increasingly the typical case) must be designed 
with some degree of resiliency or self-healing in mind.  And that 
means planning for and limiting the scope of undefined behavior.