Just Don’t Return null!

On my article Avoid Explicit null Checks i talked about alternative ways to handle a null value that don’t involve explicitly doing null checks.

After writing that article I still felt I needed to emphasize more in explaining that any of those approaches are unnecessary if we Just Don’t Return null! in the first place. Returning null is an invitation for problems, it just takes a missing null check in the calling code for chaos to happen.

If your code produces a null, instead of returning it we need to suppress it somehow. There are a few things we could do about it and we need to get used to applying one of those options because if we don’t, then it will become the responsibility of the caller to handle that null.

Returning null is a lazy and bad habit that adds unnecessary risk to your application.

Let’s now have a look at some code.

In the above example after some check for availability, an item is marked as sold and then returned. The method uses the Item return type, this means something needs to be returned even if the item is not available. It’s very tempting to just return a null reference, but this could cause problems for the caller. If the caller(or callers), fails to do a null check, it could result in a NullPointerException being thrown if some value from the item object is used. Or even worse, the null item could end up sent further all the way to the end-user or other systems and cause a lot of harm.

Let’s now have a look at what we could do instead of returning null.

Throw an exception
We could throw a runtime exception. Maybe a custom one called AvailabilityException and include an INFO log message

Not even a need for a custom exception, we could just use an IllegalArgumentException. Throwing an exception is better than returning null. Maybe some would like to argue that using exceptions to control normal business flow is not a good practice. Ok fair enough, I would agree with that. Let’s then see what other thing we could do.

Return a “Special Case” object
A special case object is something that we return instead of returning null. There’s a pattern called null value object which I have already explained in the other article so I am not going to explain it here again but instead, I am going to use Java 8 Optional.empty() which is just Java’s implementation of that patter.

Using Optional.empty() is a special case object that will safeguard the caller from a NullPointerException. Is my favourite approach instead of returning null, I personally use it a lot.

Another common example of a similar special case object is Collections.emptyList() which will return an empty List that can be very useful in similar situations where we don’t want to return null but a List is required.

Unfortunately, there are many many developers that think that just because Java allows null, it is fine to return it. But from the point of view of clean-coding and software craftsmanship, we need to take the responsibility and not let null get out of our the methods we write. Probably it would be best if we stop using null references altogether.

I hope you enjoyed this article, if you did please give some claps 👏 and/or share it with your friends on social media.