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

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

On Friday, 17 January 2014 at 21:31:16 UTC, Walter Bright wrote:
> As I replied elsewhere, tracking down the source of a bad value 
> in any variable is a standard debugging problem. There isn't 
> anything special about null in this regard.

It isn't special in the theoretical sense, but since it in 
practice is used for a wide variety of things  it becomes a 
sensitive issue in situations where you cannot replay input. 
Especially since it is used for linking together subsystems. In 
multi user games you can do fine with wrong "float values", 
objects might drift, you might get odd effects, but those bugs 
can be cool. They might even become features. A wrong "null" 
makes the client or server shut down, it is disruptive to the 
service.

So what can you do? You can log all input events in a ring buffer 
and send a big dump to the developers when the game client crash 
and try to find correlation between stack trace and input events 
(if you get multiple reports).  And on a server with say 1000 
concurrent users that interact and trigger a variety of bugs in 
one big multi-threaded global state world sim… You want to use a 
safe language for world content, where you disable features if 
needed, but keep the world running.

The same goes for a web service. You don't want to shut down the 
whole service just because the "about page" handler fails to test 
for null.

Big systems have to live with bugs, it is inevitable that they 
run with bugs. Erlang was created for stuff like that. Can you 
imagine a telephone central going down just because the settings 
for one subscriber was wrong and triggered a bug?