Why are null references shunned while throwing exceptions is considered okay?

Question

I don't quite understand the consistent bashing of null references by some programming language folks. What's so bad about them? If I request read access to a file that doesn't exist then I'm perfectly happy to get an exception or a null reference and yet exceptions are considered good but null references are considered bad. What's the reasoning behind this?

Answer 1

Null references aren't "shunned" any more so than exceptions, at least by anyone I've ever known or read. I think you're misunderstanding the conventional wisdom.

What's bad is an attempt to access a null reference (or dereference a null pointer, etc.). This is bad because it always indicates a bug; you would never do something like this on purpose, and if you are doing it on purpose, then that's even worse, because it's making it impossible to distinguish expected behaviour from buggy behaviour.

There are certain fringe groups out there who just really hate the concept of nullity for some reason, but as Ed points out, if you don't have null or nil then you'll just have to replace it with something else, which might lead to something worse than a crash (such as data corruption).

Many frameworks, in fact, embrace both concepts; for example, in .NET, a frequent pattern you'll see is a pair of methods, one prefixed by the word Try (such as TryGetValue). In the Try case, the reference is set to its default value (usually null), and in the other case, an exception is thrown. There's nothing wrong with either approach; both are used frequently in environments that support them.

It really all depends on the semantics. If null is a valid return value, as in the general case of searching a collection, then return null. On the other hand, if it is not a valid return value - for example, looking up a record using a primary key that came from your own database - then returning null would be a bad idea because the caller won't be expecting it and probably won't check for it.

It's really very simple to figure out which semantic to use: Does it make any sense for the result of a function to be undefined? If so, you can return a null reference. If not, throw an exception.

Answer 2

The big difference is that if you leave out code to handle NULLs, your code will continue on quite possibly crashing at a later stage with some unrelated error message, where as with exceptions, the exception would be raised at the initial point of failure (opening a file for reading in your example).

Answer 3

Because null values are not a necessary part of a programming language and are a consistent source of bugs. As you say, opening a file may result in failure, which could be communicated back as either a null return value or via an exception. If null values were not allowed then there is a consistent, singular way to communicate failure.

Also, this is not the most common issue with nulls. Most people remember to check for null after calling a function which may return it. The problem crops up far more in your own design by allowing variables to be null at various points in your program's execution. You can design your code such that null values are never allowed, but if null were not allowed at the language level none of this would be necessary.

However, in practice you would still need some way to signify if a variable is or is not initialized. You would then have a form of bug wherein your program does not crash, but instead continues along using some possibly invalid, default value. I honestly don't know which is better. For my money I like to crash early and often.

Answer 4

Tony Hoare, who created the idea of a null reference in the first place, calls it its one million dollar mistake.

The problem is not about null references per-se, but about the lack of proper type-checking in most (otherwise) type safe languages.

This lack of support, from the language, means that bugs "null-bugs" may be lurking in the program for a long time before being detected. Such is the nature of bugs, of course, but the "null-bugs" are now known to be avoidable.

This problem is especially present in C or C++ (for example) because of the "hard" error that it causes (a crash of the program, immediate, with no elegant recovery).

In other languages, there is always the question of how to handle them.

In Java or C# you would get an exception if you attempt to invoke a method on a null reference, and it might be okay. And therefore most of Java or C# programmers are used to this and don't understand why one would want to do otherwise (and laugh at C++).

In Haskell, you have to explicitly provide an action for the null case, and therefore Haskell programmers gloat at their colleagues, because they got it right (right ?).

It is, really, the old error-code / exception debate, but this time with a Sentinel Value in lieu of error-code.

As always whichever is most appropriate really depends on the situation and the semantics you are looking for.

Answer 5

You can't attach a human-readable error message to a null pointer.

(You can, however, leave an error message in a log file.)

In some languages/environments which allow pointer arithmetic, if one of the pointer argument is null and it is allowed into the calculation, the result would be an invalid, non-null pointer. (*) More power to you.

(*) This happens a lot in COM programming, where if you try to call into an interface method but the interface pointer is null, it would result in a call to an invalid address that is almost, but not quite, exactly unlike zero.

Answer 6

Returning NULL (or numeric zero, or boolean false) to signal an error is wrong both technically and conceptually.

Technically, you're burdening the programmer with checking the return value right away, at the exact point where it is returned. If you open twenty files in a row, and the error signalling is done by returning NULL, then the consuming code must check each file read individually, and break out of any loops and similar constructs. This is a perfect recipe for cluttered code. If, however, you choose to signal the error by throwing an exception, the consuming code can choose to handle the exception immediately, or let it bubble up as many levels as appropriate, even across function calls. This makes for much cleaner code.

Conceptually, if you open a file and something goes wrong, then returning a value (even NULL) is wrong. You don't have anything to return, because your operation didn't finish. Returning NULL is the conceptual equivalent of "I've successfully read the file, and here's what it contains - nothing". If that's what you want to express (that is, if NULL makes sense as an actual result for the operation in question), then by all means return NULL, but if you want to signal an error, use exceptions.

Historically, errors were reported this way because programming languages like C don't have exception handling built into the language, and the recommended way (using long jumps) is a bit hairy and kind of counter-intuitive.

There's also a maintenance side to the problem: with exceptions, you have to write extra code to handle the failure; if you don't, the program will fail early and hard (which is good). If you return NULL to signal errors, the default behaviour for the program is to ignore the error and just carry on, until it leads to other problems down the road - corrupt data, segfaults, NullReferenceExceptions, depending on the language. To signal the error early and loudly, you have to write extra code, and guess what: that's the part that gets left out when you're on a tight deadline.

Answer 7

As already pointed out, many languages don't convert a dereference of a null pointer into a catchable exception. Doing that is a relatively modern trick. When the null pointer issue was first recognised, exceptions hadn't even been invented yet.

If you allow null pointers as a valid case, that is a special case. You need special-case handling logic, often in lots of different places. That's extra complexity.

Whether it relates to potentially null pointers or not, if you don't use exception throws to handle exceptional cases, you must handle those exceptional cases some other way. Typically, every function call must be have checks for those exceptional cases, either to prevent the function call being called inappropriately, or to detect the failure case when the function exits. That's extra complexity that can be avoided using exceptions.

More complexity usually means more errors.

Alternatives to using null pointers in data structures (e.g. to mark the start/end of a linked list) include using sentinel items. These can give the same functionality with a lot less complexity. However, there can be other ways to manage the complexity. One way is to wrap the potentially null pointer in a smart pointer class so that the null checks are only needed in one place.

What to do about the null pointer when it's detected? If you can't build in the exceptional-case handling, you could always throw an exception, and effectively delegate that special-case handling to the caller. And that's exactly what some languages do by default when you dereference a null pointer.

Answer 8

Specific to C++, but there null references are shunned there because null semantics in C++ are associated with pointer types. It's quite reasonable for a file open function to fail and return a null pointer; in fact the fopen() function does exactly that.

Answer 9

It depends on the language.

For instance, Objective-C allows you to send a message to a null (nil) object without problems. A call to nil returns nil as well and is considered a language feature.

I personally like it since you can rely on that behavior and avoid all those convoluted nested if(obj == null) constructs.

For instance:

if (myObject != nil && [myObject doSomething])
{
    ...
}

Can be shortened to:

if ([myObject doSomething])
{
    ...
}

In short, it makes your code more readable.

Answer 10

I don't give a hoot whether you return a null or throw an exception, as long as you document it.

Answer 11

A Null reference usually occurs because something in the program logic was missed, ie: you got to a line of code without going through the required set-up for that block of code.

On the other hand, if you throw an exception for something it means that you recognized that a particular situation could occur in normal operation of the program, and it's being handled.

Answer 12

Null references are often very useful: For example, an element in a linked list can have some successor or no successor. Using null for "no successor" is perfectly natural. Or, a person can have a spouse or not - using null for "person has no spouse" is perfectly natural, much more natural than having some "has no spouse"-special value that the Person.Spouse member could refer to.

But: Many values are not optional. In a typical OOP program, I'd say more than half of the references can't be null after the initialization, or the program will fail. Otherwise the code would have to be riddled with if (x != null) checks. So why should every reference be nullable by default? It should really be the other way round: variables should be non-nullable by default, and you should explicitly have to say "oh, and this value can be null, too".

Answer 13

Your question is confusingly worded. Do you mean a null reference exception (which is actually caused by an attempt to dereference null)? The clear reason to not want that type of exception is that it gives you no information as to what went wrong, or even when -- the value could have been set to null at any point in the program. You write "If I request read access to a file that doesn't exist then I'm perfectly happy to get an exception or a null reference" -- but you should not be perfectly happy to get something that gives no indication of the cause. Nowhere in the string "an attempt was made to dereference null" is there any mention of reading or of non-existing files. Perhaps you mean that you would be perfectly happy to get null as a return value from a read call -- that's a quite different matter, but it still gives you no information about why the read failed; it's much better to receive either an error object that details the nature of the error, or to have such an error object thrown (note the distinction, and possible confusion, between an Exception, which is a object, and an exception, which is an event that results in throwing such an object).