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

Walter Bright newshound2 at digitalmars.com
Fri Jan 17 17:22:49 PST 2014


On 1/17/2014 4:44 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" 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.


More information about the Digitalmars-d mailing list