I'm a recovering null checker...

That is right, in the past I explicitly checked references to see if they are null…yea, I still have lapses, I try to avoid it - null checks are insidious in a Java code base; and by insidious I mean:

1. Are harmful but enticing.
Hey, I got a null pointer exception (NPE) when running this test. Hmm, not sure if the data is right…oh well I can just add a null check here. The check will ensure the problem will not occur again.


2. Spread harmfully, in a subtle or stealthy manner.
Similar to other types of broken windows in a code base one null check begets another. Everything starts to be confusing…
This variable was checked for null in this method so if I pass it to this method I need to check for null here as well. Quickly you have the problem of accidental, not real complexity.


3. Have a gradual and cumulative negative effect.
Individually they are not a big deal. Sure, it is not clear if it is an expected condition or just a enticing precaution someone coded. But, at some point the complexity null checks add to a codebase are over-whelming and they are a common theme in many bugs.

So, are Java null checks evil? Often they are (or at least a bad idea) and you need an approach (or two) to dealing with null values in your coding efforts.

I've been seeking better ways to deal with nulls for a while. This series of blogs distills these ideas into a catalog of approaches.  Please leave feedback if you think I've missed one or you know a better way.

---

I have a instance of a class that might be missing, in which case the reference is null.

In this example when the employee's jobRole is unassigned we say he is not due for a raise.  So, jobRole can be null. Now, to not get into trouble, everywhere we reference jobRole it needs to include null check. Obviously it is not DRY and the business rules for an unknown jobRole is strewn all over your codebase.

Fix; create a instance of the object to use when you are missing the item - known as the NullObject pattern.

Use the NullObject pattern in place of null checks.

---

I have a method that can return a null value. 

In this case we simply might have bad data or the repository has not been updated with a new city.

It doesn't seem bad for a validate method to check for null but what about other calls to the findCity method?

Hopefully callers will know to check for null - I'll just put it in the java docs ;-)

Use the return type of Optional to let callers know they need to handle absent values.

---

I want to fail fast when arguments passed into my method are null. 

Yep, very common - let us fail quickly not 5 frames into this method where it could be difficult to see the employee was null from the start.

Of course there is a better way to encapsulate this idea.

Use a common null check method to fail fast when input arguments are null.

---

When a reference is null I need to use a default value.

In this example I'm getting a package quantity for a product.  I need to use the first non-null value either quantity, inner pack quantity or a default value.

Use a common method to encapsulate selecting the first non null value.

---

I need to call a getter on an instance that might be null.

Here I am trying to return the Street portion of an Employee's address.  If anything is missing I will use an empty string as the Street name.  But I need to check for nulls at every turn.  This results in a nasty triple nested null check.

Use Optional and supplier functions to navigate an object chain that may contain nulls.

---

I need to sort on a field that could be null in some object instances.

In this compareTo method I have some employees without middle names.  So, if the first and last name are the same the compare will take into account the middle name - which could be null :-(

Yes, this is an ugly compareTo implementation - there are various utility methods that can be used to improve it - I'm going to use the Java 8 API.

Use Comparator null handling to compare instances that can be null.

---