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

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

I somehow missed this post, so a delayed response.

On Saturday, 18 January 2014 at 01:22:48 UTC, Walter Bright wrote:
> First off, in all these scenarios you describe, how does not 
> having a null make it EASIER to track down the bug?

I have not argued for not having a null. I have argued for 
trapping null, instantiating a type specific default and recover 
if the type's meta says so. That default could be to issue a 
NullException. At that point you should be able to log null 
dereferences too.

I have previously argued that non-null pointers is nice, but only 
if you have whole program analysis. Otherwise you'll end up 
injecting null-tests everywhere.

> there's a bug in the code. It's quite another to have a 
> critical system start behaving erratically because of a bug.

Yes, and this is a problematic definition since "erratic" is kind 
of subjective given that most systems don't follow the model 100%.

> do. The correct way is when the bug is detected, that software 
> is IMMEDIATELY SHUT DOWN and the backup is engaged. If you 
> don't have such a backup, you have a very, very badly designed 
> system.

In that case 99.99% of all software is very, very badly designed.

DMD inclusive.

Human beings too, but we happen to be fault tolerant, not by 
using backups, but by being good at recovery and dealing in a 
fuzzy way with incomplete or wrong information.