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.
