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?
