Null check chain vs catching NullPointerException

by

Catching NullPointerException is a really problematic thing to do since they can happen almost anywhere. It’s very easy to get one from a bug, catch it by accident and continue as if everything is normal, thus hiding a real problem. It’s so tricky to deal with so it’s best to avoid altogether. (For example, think about auto-unboxing of a null Integer.)

I suggest that you use the Optional class instead. This is often the best approach when you want to work with values that are either present or absent.

Using that you could write your code like this:

public Optional<Integer> m(Ws wsObject) {
    return Optional.ofNullable(wsObject.getFoo()) // Here you get Optional.empty() if the Foo is null
        .map(f -> f.getBar()) // Here you transform the optional or get empty if the Bar is null
        .map(b -> b.getBaz())
        .map(b -> b.getInt());
        // Add this if you want to return null instead of an empty optional if any is null
        // .orElse(null);
        // Or this if you want to throw an exception instead
        // .orElseThrow(SomeApplicationException::new);
}

Why optional?

Using Optionals instead of null for values that might be absent makes that fact very visible and clear to readers, and the type system will make sure you don’t accidentally forget about it.

You also get access to methods for working with such values more conveniently, like map and orElse.

Is absence valid or error?

But also think about if it is a valid result for the intermediate methods to return null or if that is a sign of an error. If it is always an error then it’s probably better throw an exception than to return a special value, or for the intermediate methods themselves to throw an exception.

Maybe more optionals?

If on the other hand absent values from the intermediate methods are valid, maybe you can switch to Optionals for them also?

Then you could use them like this:

public Optional<Integer> mo(Ws wsObject) {
    return wsObject.getFoo()
        .flatMap(f -> f.getBar())
        .flatMap(b -> b.getBaz())
        .flatMap(b -> b.getInt());        
}

Why not optional?

The only reason I can think of for not using Optional is if this is in a really performance critical part of the code, and if garbage collection overhead turns out to be a problem. This is because a few Optional objects are allocated each time the code is executed, and the VM might not be able to optimize those away. In that case your original if-tests might be better.

More Related Contents:

  1. IllegalArgumentException or NullPointerException for a null parameter? [closed]
  2. Avoiding NullPointerException in Java
  3. Why is my Spring @Autowired field null?
  4. Which @NotNull Java annotation should I use?
  5. Should a retrieval method return ‘null’ or throw an exception when it can’t produce the return value? [closed]
  6. How come invoking a (static) method on a null reference doesn’t throw NullPointerException?
  7. Check chains of “get” calls for null
  8. Why does String.valueOf(null) throw a NullPointerException?
  9. Filter values only if not null using lambda in Java8
  10. Is null check needed before calling instanceof?
  11. Why static fields are not initialized in time?
  12. Why use Optional.of over Optional.ofNullable?
  13. How do I avoid checking for nulls in Java?
  14. Concurrent Modification Exception : adding to an ArrayList
  15. java.rmi.ServerException: RemoteException occurred in server thread (ClassNotFoundException)
  16. Differences between Exception and Error
  17. What could cause java.lang.reflect.InvocationTargetException?
  18. Why doesn’t Java allow to throw a checked exception from static initialization block?
  19. No-throw VirtualMachineError guarantees
  20. Checking for a null int value from a Java ResultSet
  21. Exception NoClassDefFoundError for CacheProvider
  22. java.rmi.ConnectException: Connection refused to host: 127.0.1.1;
  23. How can I avoid ResultSet is closed exception in Java?
  24. While constructing the default constructor can not handle exception : type Exception thrown by implicit super constructor
  25. How to simplify a null-safe compareTo() implementation?
  26. Why null cast a parameter? [duplicate]
  27. In Java, is using throws Exception instead of throwing multiple specific exceptions good practice?
  28. When to log a stacktrace for a caught exception
  29. Understanding the difference between null and ‘\u000’ in Java
  30. Java 8 Supplier Exception handling with CompletableFuture

Leave a Comment