On 1/17/2014 4:44 PM, "Ola Fosheim Grøstad"
<[email protected]>" wrote:
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?
First off, in all these scenarios you describe, how does not having a null make
it EASIER to track down the bug?
Next, it's one thing to have a game degrade but keep playing if there's a bug in
the code. It's quite another to have a critical system start behaving
erratically because of a bug.
Remember, a bug means the program has entered an undefined, unanticipated state.
If it is a critical system, continuing to run that system is absolutely,
positively, the wrong thing to 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.
I'm not just making that stuff up; it is not my uninformed opinion. This is how,
for example, Boeing designs things for airliners. You wouldn't want it any other
way. Fukushima and Deepwater Horizon are what happens when you don't have a
system with independent backups.
Again, granted, this doesn't apply to a game. Nothing bad happens when a game
goes awry. But it definitely applies when there's money involved, like
transaction processing, or trading software. And it certainly applies when
failure means people die.
