Best way to handle nulls in Java?

Question

I have some code that is failing because of NullPointerException. A method is being called on the object where the object does not exist.

However, this led me to think about the best way to fix this. Do I always code defensively for nulls so that I future proof code for null pointer exceptions, or should I fix the cause of the null so that it won't occur downstream.

What are your thoughts?

Answer 1

If null is a reasonable input parameter for your method, fix the method. If not, fix the caller. "Reasonable" is a flexible term, so I propose the following test: How should the method hande a null input? If you find more than one possible answer, then null is not a reasonable input.

Answer 2

There are multiple ways to handle this, peppering your code with if (obj != null) {} is not ideal, it is messy, it adds noise when reading the code later during the maintenance cycle and is error prone, as it is easy to forget to do this boiler plate wrapping.

It depends on if you want the code to continue executing quietly or fail. Is the null an error or an expected condition.

What is null

In every defintion and case, Null represents the absolute lack of data. Nulls in databases represent the lack of a value for that column. a null String is not the same as an empty String, a null int is not the same thing as ZERO, in theory. In practice "it depends". Empty String can make a good Null Object implementation for the String class, for Integer it depends on the business logic.

Alternatives are:

1. The Null Object pattern. Create an instance of your object that represents the null state, and initialize all references to that type with a reference to the Null implementation. This is useful for simple value type objects that don't have a lot of references to other objects that could also be null and is expected to be null as a valid state.

2. Use Aspect Oriented tools to weave methods with a Null Checker aspect that prevents the parameters from being null. This is for cases where null is an error.

3. Use assert() not much better than the if (obj != null){} but less noise.

4. Use a Contract Enforcement tool such as Contracts For Java. Same use case as something like AspectJ but newer and uses Annotations instead of external configuration files. Best of both works of Aspects and Asserts.

1 is the ideal solution when incoming data is known to be null and needs to be replaced with some default value so that upstream consumers won't have to deal with all the null checking boilerplate code. Checking against known default values will be more expressive as well.

2, 3, and 4 are just convenient alternative Exception generators to replace NullPointerException with something more informative, which is always and improvement.

In the End

null in Java is almost in all cases a logic error. You should always strive to eliminate the root cause of NullPointerExceptions. You should strive to not use null conditions as business logic. if (x == null) { i = someDefault; } just make the initial assigment to that default object instance.

Answer 3

I would recommend fixing the method to be defensive. For instance:

String go(String s){  
    return s.toString();  
}

Should be more along the lines of this:

String go(String s){  
    if(s == null){  
       return "";  
    }     
    return s.toString();  
}

I realize this is absolutely trivial, but if the invoker expects an object give them a default object that won't cause a null to be passed around.

Answer 4

Well if one of the possible outcomes of your method is a null value then you should code defensively for that, but if a method is supposed to return a non-null but isn't I would fix that for sure.

As usual it depends on the case, as with most things in life :)

Answer 5

tl;dr - it is GOOD to check for unexpected nulls but BAD for an application to try to make them good.

Details

Clearly, there are situations where null is a valid input or output to a method, and others where it is not.

Rule #1:

The javadoc for a method that allows a null parameter or returns a null value must clearly document this, and explain what the null means.

Rule #2:

An API method should not be specified as accepting or returning null unless there is a good reason to do so.

Given a clear specification of a method's "contract" vis-a-vis nulls, it is a programming error to pass or return a null where you shouldn't.

Rule #3:

An application should not attempt to "make good" programming errors.

If a method detects a null that shouldn't be there, it should not attempt to fix the problem by turning it into something else. That just hides the problem from the programmer. Instead, it should allow the NPE to happen, and cause a failure so that the programmer can figure out what the root cause is and fix it. Hopefully the failure will be noticed during testing. If not, that says something about your testing methodology.

Rule #4:

Where feasible, write your code to detect programming errors early.

If you've got bugs in your code that result in lots of NPEs, the hardest thing can be figuring out where the null values came from. One way to make diagnosis easier is to write your code so that the null is detected as soon as possible. Often you can do this in conjunction with other checks; e.g.

public setName(String name) {
    // This also detects `null` as an (intended) side-effect
    if (name.length() == 0) {
        throw new IllegalArgumentException("empty name");
    }
}

(There are obviously cases where rules 3 and 4 should be tempered with reality. For instance (rule 3), some kinds of applications must attempt to continue after detecting probably programming errors. And (rule 4) too much checking for bad parameters can have a performance impact.)

Answer 6

Apache Commons' lang libraries provide a way to handle null values

the method defaultIfNull in the class ObjectUtils enables you to return a default value if the object passed is null

Answer 7

The following general rules about null have helped me a lot so far :

1. If the data comes from outside your control, systematically check for nulls and act appropriately. This means either throwing an exception that makes sense to the function (checked or unchecked, just make sure the name of the exception tells you exactly what is going on.). But NEVER lest a value loose in your system that can potentially carry surprises.

2. If Null is within the domain of appropriate values for your data model, deal with it appropriately.

3. When returning values try to not return nulls whenever possible. Always prefer Empty lists, empty strings, Null Object patterns. Keep nulls as returned values when this is the best possible representation of data for a given use case.

4. Probably the most important of all... Tests, tests and test again. When testing your code do not test it as a coder test it as a Nazi psychopath dominatrix and try to imagine all sorts of ways to torture the hell out of that code.

This tends a bit on the paranoid side regarding nulls often leading to façades and proxies that interface systems to the outside world and strictly controlled values in the inside with abundant redundancy. The outside world here means pretty much everything I did not code myself. It does bear a cost runtime but so far I rarely had to optimize this by creating "null safe sections" of code. I must say though that I mostly create long running systems for health care and the last thing I want is the interface subsystem carrying your iodine allergies to the CT scanner crashes because of an unexpected null pointer because someone else in another system never realized that names could contain apostrophes or characters like 但耒耨。

anyways.... my 2 cents