On 01/19/2014 12:01 AM, "Ola Fosheim Grøstad"
<[email protected]>" wrote:
On Saturday, 18 January 2014 at 02:59:43 UTC, Walter Bright wrote:
On 1/17/2014 6:42 PM, "Ola Fosheim Grøstad"
<[email protected]>" wrote:
But then you have to define "invalid state",
An unexpected value is an invalid state.
It is only an invalid state for a subsystem, if your code is written to
handle it, it can contain it and recover (or disable that subsystem).
Assuming that you know that it unlikely to be caused by memory corruption.
...
This is not a plausible assumption. What you tend to know is that the
program is unlikely to fail because otherwise it would not have been
shipped, being safety critical. I.e. when it fails, you don't know that
it is unlikely to be caused by something. It could be hardware failure,
and even a formal correctness proof does not help with that.
The problem with being rigid on this definition is ...
He is not.
What is the essential difference between insisting on stopping a program
with bugs and insisting on not starting a program with bugs? There is no
difference.
...
Irrelevant. He is arguing for stopping the system once it has _become
clear_ that the _current execution_ might not deliver the expected results.
