Non-null objects, the Null Object pattern, and T.init

Timon Gehr timon.gehr at gmx.ch
Sun Jan 19 00:41:22 PST 2014


On 01/19/2014 12:01 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" 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"
>> <ola.fosheim.grostad+dlang at gmail.com>" 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.


More information about the Digitalmars-d mailing list