Three ways to avoid null in object oriented languages (Java)


The most common line of code that I’ve seen must be:

It’s purpose is usually to avoid the most common exception that I’ve seen thrown in runtime, NullPointerException.


Null checks are a necessity sometimes but when I see pervasive null checks I consider them being a code smell. I can justify null checks on what I call the “end-points” of software. Let’s say that I am building a simple web-service using some business logic and a database. I find it appropriate to have null checks when receiving external requests to my service and when working with my database. Null checks in the business layer are pointless since that’s already been done.*

* Only applies to code you own. A map that can return null will always need a null check.

Implicit logic

The worst use of null checks is when null is returned to mediate implicit logic. I’ll show what I mean with an example. Let’s say you do something like this:

What happens in the else clause? Does this mean that the database is offline? Is everything working but the user doesn’t exist? Should the user be created?

Example 1 – Avoid Mediation Logic With Polymorphism

There are many solutions to these problems. First I’d like to address that which can be solved by using polymorphism properly. Let’s say you have the following class:

…used in following way:


Let’s say that you suddenly need to enable some users to have an administrator account and you need to implement it quickly. Some developers will do the following changes:

 …and now all usages will need to look like this:

Now the product owner introduces managers who are users with a normal account, an admin account and a list of team members.

…and now typical usage will look like this:

Things now look horrible and even though it might seem like I’m exaggerating, I’ve seen code similar to this. I prefer to solve it with the help of the Visitor Pattern:

This would change the usage to:


Example 2 – Immutability and assertion

Making objects immutable ensures that all fields are set once and only once. To ensure that objects are set to something other than null you can either use assertion or throw and exception. Assertion can be enabled when testing and be disabled when the software is running in production. Throwing an exception is the way I prefer to do it.


Example 3 – Null Object

It’s easy to avoid null when using collections. Simply use empty collections. All loops will iterate without runtime exceptions. In Java, and most other OO-languages, there are predefined empty collections such as Collections.emptyList(). For non-collections it is preferable to define a null object. It is recommended to introduce an interface to make this possible.



Using proper polymorphism, immutability and null object can reduce null pointer exceptions in your code. Readability is increased and therefore maintainability is increased as well. There are arguments for not using these methods. In some domains null is considered a standard that should be used to mediate logic. In small systems you can argue that my examples are overambitious. If anyone has any suggestions to improve my examples or simply discuss further then please comment.

One thought on “Three ways to avoid null in object oriented languages (Java)

  1. I agree 100%. Try your best to not return null values if you can return an empty collection or an empty (or null) object instead.

    From a client-code perspective, perhaps Optional is the best, or at least the most explicit, way to deal with violations to this advice?

    Another reason to read up on the old trusted Visitor pattern is to avoid code stink like RTTI, e. g. instanceof. Just as important in Java as in C++. That’s the only reason why I immediately recognize this pattern.

Leave a Reply

Your email address will not be published. Required fields are marked *

6 + 3 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">