This blog post called Returning None is evil caught my attention. In this article, the author (Marty Alchin) tries to explain why you should never return None (this is Python’s equivalent of None). Since he also takes this opportunity to take a few unnecessary potshots at Java, I thought I’d make a few comments.

Marty seems to be prone to exaggeration. For example, he states that NullPointerExceptions (or rather, their Python equivalent) are:

exceptionally hard to debug

It typically takes me less than a minute to find such errors. The first ten seconds are dedicated to jumping to the place where the exception occurred, and the remaining to finding where that value came from (usually instantaneous with Java IDE’s. Python doesn’t have those… pity).

Marty then continues by saying that returning a None value indicates that

an error occurred

Well, not always. For example, when you look up a key that doesn’t exist in a dictionary, is this an error? It seems very much part of the contract of the class to me. There are many, many other situations where the fact that a value cannot be returned is not an error (such as looking up a configuration preference). Throwing an exception in these cases is not just a waste, it complicates the caller code needlessly and it deceives future readers into thinking that something very wrong occurred.

If you’re using Python (which I hope you are), embrace exceptions.

Absolutely. And Java programmers embrace exceptions just as much as Python developers (I’d argue that Java’s exception system is more sophisticated since it allows for both checked and unchecked exceptions, but let’s not digress).

I hope I’ve made the point well enough without writing a song called Raise an Exception. Whatever you do, don’t return None unless None represents some usefulness to your code.

Well… so what do we do? Unfortunately, the article ends here. At least if you’re going to criticize, offer a few suggestions to remedy the problem, will you?

Here is a scoop: exception should only be thrown for exceptional situations. Not finding a configuration value is not exceptional. Not finding a word in a document is not exceptional: it can happen, it’s even expected to happen, and it’s perfectly okay if it does.

So, what are we supposed to do when the situation is not exceptional and that, according to Marty, we can’t return None either? His post is interestingly silent on this, so let me try to offer a suggestion.

There is a design pattern known as the Null Object, which also tries to minimize the number of NullPointerExceptions one can encounter in the code. The idea is that when you are tempted to return null, you return an empty object of the desired type. This saves the user from testing for null, but it’s also fraught with all kinds of problems that I won’t get into, so it’s hardly ever used.

My advice: there is nothing wrong with returning null/None. All you need to do when you’re wondering whether you should throw an exception instead of returning null is whether the current situation is an error or whether it is expected to happen.