Why are null references shunned while throwing exceptions is considered okay

exceptionsnullprogramming-languages

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?

Best Answer

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.

Related Solutions

Why Doesn’t ‘Object Reference Not Set to an Instance of an Object’ Specify Which Object?

The NullReferenceException basically tells you: you are doing it wrong. Nothing more, nothing less. It's not a full-fledged debugging tool, on the contrary. In this case I'd say you're doing it wrong both because

there is a NullReferenceException
you didn't prevent it in a way you know why/where it happened
and also maybe: a method requiring 20 objects seems a bit off

I'm a big fan of checking everything before things start going wrong, and providing good information to the developer. In short: write checks using ArgumentNullException and the likes and write the name yourself. Here's a sample:

void Method(string a, SomeObject b)
{
    if (a == null) throw ArgumentNullException("a");
    if (b == null) throw ArgumentNullException("b");

    // See how nice this is, and what peace of mind this provides? As long as
    // nothing modifies a or b you can use them here and be 100% sure they're not
    // null. Should they be when entering the method, at least you know which one
    // is null.
    var c = FetchSomeObject();
    if(c == null)
    {
        throw InvalidOperationException("Fetching B failed!!");
    }

    // etc.
}

You could also look into Code Contracts, it has it quirks but it works pretty well and saves you some typing.

Exceptions – Why Option/Maybe Is Preferred Over Checked Exceptions

Because Options are composable. There are a lot of useful methods on Option that allow you to write concise code, while still allowing precise control on the flow: map, flatMap, toList, flatten and more. This is due to the fact that Option is a particular kind of monad, some objects that we know very well how to compose. If you did not have these methods and had to pattern match always on Option, or call isDefined often, they would not be nearly as useful.

Instead, while checked exceptions do add some safety, there is not much you can do with them other than catching them or let them bubble up the stack (with the added boilerplate in the type declaration).

Best Answer

Related Solutions

Why Doesn’t ‘Object Reference Not Set to an Instance of an Object’ Specify Which Object?

Exceptions – Why Option/Maybe Is Preferred Over Checked Exceptions

Related Topic