Avoiding Excessive Null Checks in Java: Using Assertions, Exceptions, and the Null Object Pattern

In Java projects, developers often write repetitive null‑check statements like if (someObject != null) { someObject.doCalc(); } , which makes the codebase bulky and hard to read.

The article first separates two scenarios: (1) when null is a meaningful, contract‑defined return value, and (2) when null indicates an invalid or erroneous condition.

For the second case, the recommended approaches are to use assert statements with explanatory messages or to throw a NullPointerException (or a custom exception) immediately, signalling that the caller supplied an illegal null argument.

When null is a legitimate response, the article suggests returning an empty collection instead of null , allowing callers to safely invoke methods like list.size() without additional checks.

If the method returns a non‑collection type, the advice is to return a neutral “empty” object rather than null . The Null Object pattern is illustrated with the following interfaces:

public interface Action { void doSomething(); }
public interface Parser { Action findAction(String userInput); }

and an implementation that guarantees a non‑null result:

public class MyParser implements Parser {
    private static final Action DO_NOTHING = new Action() {
        public void doSomething() { /* do nothing */ }
    };
    public Action findAction(String userInput) {
        // ...
        if (/* cannot find any actions */) {
            return DO_NOTHING;
        }
        // otherwise return a real Action
    }
}

Using this pattern, client code can be simplified from a verbose null‑check chain:

Parser parser = ParserFactory.getParser();
if (parser == null) { /* handle error */ }
Action action = parser.findAction(someInput);
if (action == null) { /* do nothing */ } else { action.doSomething(); }

to a concise one‑liner:

ParserFactory.getParser().findAction(someInput).doSomething();

Additional tips include preferring "bar".equals(foo) over foo.equals("bar") to avoid accidental NullPointerException , and using Java 8's Optional to encapsulate potentially absent values.