WARNING 1! NPE when calling an instance method via a null object
Consider the following code written by a client of ChainSaw:
ChainSaw cs = ChainSaw.initChainSaw(“QW-T650”); cs.start(); // ‘cs’ is null
The client passes a chainsaw model that is not supported by this class, so the initChainSaw() method returns null. This is really bad because every time the client uses the cs variable will get back an NPE as follows:
Exception in thread “main” java.lang.NullPointerException: Cannot invoke “modern.challenge.ChainSaw.start()” because “cs” is null
at modern.challenge.Main.main(Main.java:9)
Instead of returning null, is better to throw an explicit exception that informs the client that he cannot continue because we don’t have this chainsaw model (we can go for the classical IllegalArgumentException or, the more suggestive in this case (but quite uncommon for null values handling), UnsupportedOperationException). This may be the proper fix in this case, but it is not universally true. There are cases when is better to return an empty object (for example, an empty string, collection, array) or a default object (for example, an object with minimalist settings) that doesn’t break the client code. Since JDK 8, we can use Optional as well (for a detailed explanation and best practices consider Java Coding Problems, First Edition, Chapter 12). And, of course, there are cases when returning null makes sense but that is more common in APIs and special situations.
WARNING 2! NPE when accessing (or, modifying) field of a null object
Consider the following code written by a client of ChainSaw:
ChainSaw cs = ChainSaw.initChainSaw(“QW-T650”);
boolean isStarted = cs.started; // ‘cs’ is null
Practically, the NPE, in this case, has the same root cause as the previous case. We try to access the started field of ChainSaw. Since this is a primitive boolean it was initialized by JVM with false, but we cannot “see” that since we try to access this field through a null variable represented by cs.
WARNING 3! NPE when null is passed in method argument
Consider the following code written by a client of ChainSaw:
ChainSaw cs = ChainSaw.initChainSaw(null);
You are not a good citizen if you want a null ChainSaw, but who am I to judge?! This is possible to happen and will lead to the following NPE:
Exception in thread “main” java.lang.NullPointerException: Cannot invoke “String.endsWith(String)” because “model” is null
at modern.challenge.ChainSaw.initChainSaw(ChainSaw.java:25)
at modern.challenge.Main.main(Main.java:16)
The message is crystal clear. We attempt to call the String.endWith() method with a null argument represented by the model variable. To fix this issue, we have to add a guard condition to ensure that the passed model argument is not null (and eventually, not empty). In this case, we can throw an IllegalArgumentException to inform the client that we are here and we are guarding. Another approach may consist of replacing the given null with a dummy model that passes through our code without issues (for instance, since the model is a String, we can reassign an empty string “”). However, personally, I don’t recommend this approach, not even for small methods. You never know how the code will evolve and such dummy reassignments can lead to brittle code.