Program logic bugs vs input/environmental errors

[Kagamin via Digitalmars-d]

On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> You're using a different definition of "component".

System granularity is decided by the designer. You either allow 
people design their systems or force your design on them, if you 
do both, you contradict yourself.

> An inconsistency in a transaction is a problem with the input, 
> not a problem with the program logic itself.

Distinction between failures doesn't matter. Reliable system 
manages any failures, especially unexpected and unforeseen ones, 
without diagnostic.

> If something is wrong with the input, the program
> can detect it and recover by aborting the transaction (rollback 
> the
> wrong data). But if something is wrong with the program logic 
> itself
> (e.g., it committed the transaction instead of rolling back 
> when it
> detected a problem) there is no way to recover within the 
> program
> itself.

Not the case for an airplane: it recovers from any failure within 
itself. Another indication that an airplane example contradicts 
to Walter's proposal. See my post about the big picture.

> A failed component, OTOH, is a problem with program logic. You 
> cannot
> recover from that within the program itself, since its own 
> logic has
> been compromised. You *can* rollback the wrong changes made to 
> data by
> that malfunctioning program, of course, but the rollback must 
> be done by
> a decoupled entity outside of that program. Otherwise you might 
> end up
> causing even more problems (for example, due to the compromised 
> /
> malfunctioning logic, the program commits the data instead of 
> reverting
> it, thus turning an intermittent problem into a permanent one).

No misunderstanding, I think that Walter's idea is good, just not 
always practical, and that real critical systems don't work the 
way he describes, they make more complicated tradeoffs.