On Null

A null, in computer programming, is not a thing but its absence. Suppose you have a list, a handy object that programmers use all the time. You can do many things to a list object — add an item to it (list.add(item)), count the number of items (list.count()), iterate through the items one by one. Your list might have items in it, it might be empty. Doesn’t matter, these methods will still work. But if your list is null it is not a list at all. If you try to call a method on the null list, or on any null object, your program will except, in every computer language known to man, as it should. Nothing can never do something.

You might imagine that all nothings are the same; not so. A variable that has not yet been set to a value — “uninitialized” in the parlance — is nothing, but not null. If you try to use an uninitialized variable your program will not only fail to run, it won’t even compile. Nor are all nulls created equal. Microsoft’s C#, the language in which I’m programming at the moment, has a programming null, called null, and a database null, called System.DBValue.Null. Are they equal? No such luck. Some other languages have three different nulls or more.

Everyone, I trust, has tried to visit a database-driven web site and been greeted by an error page with some gibberish like “SQL Error Column[0] invalid value NullValueException 1003.” This means that a careless programmer has allowed a null into his database and failed to check for it on retrieval. Nulls will not stand such rough treatment.

Nulls sound like a nuisance, and they are. In my experience nearly half of all programming errors can be attributed to their improper use. The layman might wonder what possible use there can be in such a thing as nothing. Here’s an instance. I’m writing a program now that involves constructing on a server long lists of complicated objects, containing many subobjects, and sending them to various clients. Creating all the subobjects takes a long time, so to improve performance and reduce network traffic I have the server “proxy” them, by sending a skeletal object to the client and not filling it out until the client specifically requests the details.

Here nulls prove their mettle. Suppose the subobject is a list, which might be empty. The server will send the parent object back with this list set to null. Now, when the client needs the list, it simply checks if the list is null, and if so, calls the server again to request it. The server returns a non-null, but possibly empty, list, and the client now knows that it has a valid list and need not bother the server for it again. Without nulls the client would not know, if the list was empty, whether to return to the server and ask for it. With nulls the client always knows to fetch the list exactly once. There are other ways to implement this kind of logic, but they are far more complex and prone to error.

Nothing can sometimes be a very beautiful thing indeed.