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

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Sunday, 19 January 2014 at 08:41:23 UTC, Timon Gehr wrote:
> 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 feel that this "safety critical" argument is ONE BIG RED 
HERRING.

It is completely irrelevant to the topic which is whether it is 
useful to have recovery mechanisms for null-pointers or not. It 
is, but not if you are forced to use them. Nobody suggests that 
you should be forced to recover from a null dereference?

Nevertheless: If your application is safety critical and not 
proven correct or have not undergone exhaustive testing (all 
combinations of input) then it most likely is a complex system 
which is likely to contain bugs. You can deal with this by 
partitioning the system into independent subsystems (think 
functional programming) which you in a domain specific manner 
control (e.g. you can have multiple algorithms and select the 
median value or the most conservative estimate, spinning down 
subsystems reverting to a less optimal state (more resource 
demanding), running a verifier on the result etc etc.

> 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.

But hardware failure is not a valid issue when discussing 
programming language constructs?

Of course the system design should account for hardware failure, 
extreme weather that makes sensors go out of range and a drunken 
sailor pressing all buttons at once.

Not a programming language construct topic.

> Irrelevant. He is arguing for stopping the system once it has 
> _become clear_ that the _current execution_ might not deliver 
> the expected results.

Then you have to DEFINE what you mean by expected results. Which 
is domain specific, not a programming language construct issue in 
a general programming language.

If the expected result is defined be: having a result is better 
than no result, then stopping the system is the worst thing you 
could do.

If the expected result controls N different systems then it might 
be better to fry 1 system and keep N-1 systems running than to 
fry N systems. That's a domain specific choice the system 
designer should have the right to make. Sacrifice one leg to save 
the other limbs.

Think about the effect of this: 1 router detects a bug, by the 
logic in this thread it should then notify all routers running 
the same software and tell them to shut down immediately. Result: 
insta-death to entire Internet.