Program logic bugs vs input/environmental errors

[Bruno Medeiros via Digitalmars-d]

On 29/09/2014 05:03, Sean Kelly wrote:
>> I recall Toyota got into trouble with their computer controlled cars
>> because of their idea of handling of inevitable bugs and errors. It
>> was one process that controlled everything. When something unexpected
>> went wrong, it kept right on operating, any unknown and unintended
>> consequences be damned.
>>
>> The way to get reliable systems is to design to accommodate errors,
>> not pretend they didn't happen, or hope that nothing else got
>> affected, etc. In critical software systems, that means shut down and
>> restart the offending system, or engage the backup.
>
> My point was that it's often more complicated than that.  There have
> been papers written on self-repairing systems, for example, and ways to
> design systems that are inherently durable when it comes to even
> internal errors.  I think what I'm trying to say is that simply aborting
> on error is too brittle in some cases, because it only deals with one
> vector--memory corruption that is unlikely to reoccur.  But I've watched
> always-on systems fall apart from some unexpected ongoing situation, and
> simply restarting doesn't actually help.

Sean, I fully agree with the points you have been making so far.
But if Walter is fixated on thinking that all the practical uses of D 
will be critical systems, or simple (ie, single-use, non-interactive) 
command-line applications, it will be hard for him to comprehend the 
whole point that "simply aborting on error is too brittle in some cases".

PS: Walter, what browser to you use?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros