Non-null objects, the Null Object pattern, and T.init
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Fri Jan 17 16:44:55 PST 2014
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?
More information about the Digitalmars-d
mailing list