When is it OK to catch NullPointerException?
Effective java recommend that we shouldn't catch NullPointerException. Is it always right?
In nearly all cases it is correct.
NullPointerException
is usually a result of a bug; i.e. your application encountered a null
object reference in a situation where it was not anticipated, and then attempted to use it. In this scenario, since you (the programmer) did not anticipate the null
, it is next to impossible to know whether it is safe to attempt to recover, and / or to know what "remediation" might be required. So the best thing to do is to let the NPE propagate to the base level, and then treat it as a generic bug. (In "network service" applications, it may be appropriate to return a "service error" response, and attempt to continue.)
The other scenario is where you (the programmer) anticipate that a null
might be delivered. In this case, the best strategy is (nearly always) to explicitly test for the null
before you attempt to use it, thereby avoiding the NPE ... and the need to handle it. There are two reasons for this:
Exception handling is typically expensive. Indeed it can be many orders of magnitude more expensive than testing for a
null
.If you allow the expected NPE to happen and then catch it, you are liable to also catch other unexpected NPEs ... and handle them incorrectly.
Note that I qualified the above by saying "nearly always". It is theoretically possible to have a scenario where explicit tests for null
clutter up your code so much that it is at least worth considering allowing the NPE to happen. However, there is still the possibility of unexpected NPEs as well ... depending on the code. So this approach is always potentially fragile.
(FWIW - I've never encountered a real case where this would be a good idea ...)
In many cases of catching NullPointerException, catch body only calls printStackTrace().
That is probably bad code. Doing nothing is rarely the correct way to recover from an NPE.
If I don't catch NullPointerException and call printStackTrace(), how I can check the place where the exception occurred?
You let the NPE propagate to the base level. There you catch and print (or log) a stacktrace for all unhandled exceptions, and then either bail out or attempt to recover ... if that is feasible.
And also if I catch NullPointerException and the catch body is empty, we cannot get any stack information at that time, can we?
Never, ever do this! It is called "squashing" and is dangerous. (Especially since, as I explained above, the NPE may be due to something that you / your code did not anticipate.)
And no, if you do this, you can't get the stack trace. It is gone.
FOLLOWUP
I don't place much trust / faith on some general strategies for "avoiding NPEs"1. For instance stuff like this:
return (someObject != null) ? someObject.toString() : "";
always make me suspicious that the programmer is not thinking about the problem. Why was someObject
a null
in the first place?
A NPE is caused by having a null
in place where you don't expect it. As such, NPEs are usually symptoms of a problem rather than the actual problem itself. To my mind, NPEs are not something to be avoided. Rather, you should be using the NPEs to find and fix the root cause of the unexpected null
. Code like the above that avoids the NPE gets in the way of that goal.
So I prefer / recommend strategies for avoiding null
values in unexpected places.
Make sure that every reference field is gets initialized to a non-null value ... unless
null
is a meaningful value.Try to avoid having
null
as a meaningful value, especially if there is an alternative. For instance, an empty String, a zero length array, an empty collection, a distinguished instance that means "undefined" or whatever. Or, for Java 8 and later, useOptional
.Don't return
null
as an error or an indication of a special case. (Throw an exception or return a distinguished value.)Check early for unanticipated
null
values (e.g.null
arguments), and throw the NPE sooner rather than later.In the few places where a
null
argument or result is legitimate, make sure that your javadocs document this clearly and explicitly. If there is no documentation, then the implication should be thatnull
is not allowed and won't be returned.
And wherever you get an NPE, make sure that you find and fix the real source of the problem ... not just the specific statement that threw the exception.
1 - There is value in knowing about places in the standard Java APIs where null
is used (or abused) as a return value. For instance, Class.getResourceAsStream(...)
or HttpRequest.getParam(...)
. Those "advice for avoiding NPE" documents are useful in as much that they point out these traps.
What is a NullPointerException, and how do I fix it?
There are two overarching types of variables in Java:
Primitives: variables that contain data. If you want to manipulate the data in a primitive variable you can manipulate that variable directly. By convention primitive types start with a lowercase letter. For example variables of type
int
orchar
are primitives.References: variables that contain the memory address of an
Object
i.e. variables that refer to anObject
. If you want to manipulate theObject
that a reference variable refers to you must dereference it. Dereferencing usually entails using.
to access a method or field, or using[
to index an array. By convention reference types are usually denoted with a type that starts in uppercase. For example variables of typeObject
are references.
Consider the following code where you declare a variable of primitive type int
and don't initialize it:
int x;
int y = x + x;
These two lines will crash the program because no value is specified for x
and we are trying to use x
's value to specify y
. All primitives have to be initialized to a usable value before they are manipulated.
Now here is where things get interesting. Reference variables can be set to null
which means "I am referencing nothing". You can get a null
value in a reference variable if you explicitly set it that way, or a reference variable is uninitialized and the compiler does not catch it (Java will automatically set the variable to null
).
If a reference variable is set to null either explicitly by you or through Java automatically, and you attempt to dereference it you get a NullPointerException
.
The NullPointerException
(NPE) typically occurs when you declare a variable but did not create an object and assign it to the variable before trying to use the contents of the variable. So you have a reference to something that does not actually exist.
Take the following code:
Integer num;
num = new Integer(10);
The first line declares a variable named num
, but it does not actually contain a reference value yet. Since you have not yet said what to point to, Java sets it to null
.
In the second line, the new
keyword is used to instantiate (or create) an object of type Integer
, and the reference variable num
is assigned to that Integer
object.
If you attempt to dereference num
before creating the object you get a NullPointerException
. In the most trivial cases, the compiler will catch the problem and let you know that "num may not have been initialized
," but sometimes you may write code that does not directly create the object.
For instance, you may have a method as follows:
public void doSomething(SomeObject obj) {
// Do something to obj, assumes obj is not null
obj.myMethod();
}
In which case, you are not creating the object obj
, but rather assuming that it was created before the doSomething()
method was called. Note, it is possible to call the method like this:
doSomething(null);
In which case, obj
is null
, and the statement obj.myMethod()
will throw a NullPointerException
.
If the method is intended to do something to the passed-in object as the above method does, it is appropriate to throw the NullPointerException
because it's a programmer error and the programmer will need that information for debugging purposes.
In addition to NullPointerException
s thrown as a result of the method's logic, you can also check the method arguments for null
values and throw NPEs explicitly by adding something like the following near the beginning of a method:
// Throws an NPE with a custom error message if obj is null
Objects.requireNonNull(obj, "obj must not be null");
Note that it's helpful to say in your error message clearly which object cannot be null
. The advantage of validating this is that 1) you can return your own clearer error messages and 2) for the rest of the method you know that unless obj
is reassigned, it is not null and can be dereferenced safely.
Alternatively, there may be cases where the purpose of the method is not solely to operate on the passed in object, and therefore a null parameter may be acceptable. In this case, you would need to check for a null parameter and behave differently. You should also explain this in the documentation. For example, doSomething()
could be written as:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj == null) {
// Do something
} else {
// Do something else
}
}
Finally, How to pinpoint the exception & cause using Stack Trace
What methods/tools can be used to determine the cause so that you stop
the exception from causing the program to terminate prematurely?
Sonar with find bugs can detect NPE.
Can sonar catch null pointer exceptions caused by JVM Dynamically
Now Java 14 has added a new language feature to show the root cause of NullPointerException. This language feature has been part of SAP commercial JVM since 2006.
In Java 14, the following is a sample NullPointerException Exception message:
in thread "main" java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because "list" is null
List of situations that cause a NullPointerException
to occur
Here are all the situations in which a NullPointerException
occurs, that are directly* mentioned by the Java Language Specification:
- Accessing (i.e. getting or setting) an instance field of a null reference. (static fields don't count!)
- Calling an instance method of a null reference. (static methods don't count!)
throw null;
- Accessing elements of a null array.
- Synchronising on null -
synchronized (someNullReference) { ... }
- Any integer/floating point operator can throw a
NullPointerException
if one of its operands is a boxed null reference - An unboxing conversion throws a
NullPointerException
if the boxed value is null. - Calling
super
on a null reference throws aNullPointerException
. If you are confused, this is talking about qualified superclass constructor invocations:
class Outer {
class Inner {}
}
class ChildOfInner extends Outer.Inner {
ChildOfInner(Outer o) {
o.super(); // if o is null, NPE gets thrown
}
}
Using a
for (element : iterable)
loop to loop through a null collection/array.switch (foo) { ... }
(whether its an expression or statement) can throw aNullPointerException
whenfoo
is null.foo.new SomeInnerClass()
throws aNullPointerException
whenfoo
is null.Method references of the form
name1::name2
orprimaryExpression::name
throws aNullPointerException
when evaluated whenname1
orprimaryExpression
evaluates to null.a note from the JLS here says that,
someInstance.someStaticMethod()
doesn't throw an NPE, becausesomeStaticMethod
is static, butsomeInstance::someStaticMethod
still throw an NPE!
* Note that the JLS probably also says a lot about NPEs indirectly.
If catching null pointer exception is not a good practice, is catching exception a good one?
Pokemon exception-handling is bad. Especially, if it's an empty block and you're simply swallowing them. You have specifically-typed exceptions for the reason that they actually mean specific things in specific contexts (essentially they're telling you what went wrong). So by catching Exception
you're saying that you don't care what those exceptions are and that you don't care what happened. This is probably not what you want.
In general, when catching exceptions follow these rules:
- Does it make sense to handle the exception at this level? If yes, then handle it. If not, then propagate.
- In conjunction with the first rule, "handling" can also mean, catching, wrapping, and re-throwing. This is a way of preventing abstraction-leakage so that callers of your method don't have to know about the underlying implementation.
- An empty catch block doesn't mean that you've handled the exception. That's called "swallowing"; at the very least, you want to log the exception. Sometimes an exception happening is actually part of the logical flow of your code, and so you might want to do something special (but this is, pardon the pun, the exception rather than the rule. It is better to check for situations that cause exceptions rather than incorporating them into the logical flow of your code).
You can easily check for a null value in your code, so there is no need to explicitly catch a null-pointer exception. It doesn't make sense to let a NullPointerException
happen (and it's bad practice). Even if you have some code that throws a NullPointerException
, and it is code that you do not control and cannot fix, you should determine the input parameters that cause the NullPointerException
and specifically test for them.
Another exception that you shouldn't catch is the IllegalArgumentException
. This exception means that you've passed in an argument that does not make sense. Instead of catching this exception, you should explicitly test your input parameters to ensure that they are sane and that they cannot cause an IllegalArgumentException
.
Null check chain vs catching NullPointerException
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 Optional
s 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 Optional
s 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.
Is Catching a Null Pointer Exception a Code Smell?
Yes, catching any RuntimeException
is almost always a code smell. The C2 Wiki seems to agree.
An exception would probably be some specially defensive pieces of code which run pretty much random code from other modules. Examples for such defensive structures would be the EDT, ThreadPools/Executors and plugin system.
Best practise in catching and throwing nullpointerexception?
A nullpointerexception usually indicates a programmer error. You won't catch a null pointer exception if you don't expect such a programmer error. For instance, say you implement a method myMethod with one parameter of type P.
void myMethod(P x)
Let's say you don't expect the parameter x to be null. In this case you might not check for null. Why? because you assume that the programmer who is using your method will use it properly and won't pass null. I'm not saying whether you should or shouldn't check for null in such cases. I'm just trying to answer why sometimes a null pointer exception is thrown by a method and isn't supposed to be caught. Here's why: Your method might throw a null pointer exception because someone didn't use it right (passed null). The programmer who is using your method might know that if the method is being used wrong it might throw a nullpointerexcetption. But even if he uses your method wrong the exception won't be caught because everyone assumes that the method isn't misused.
Your second question: First, a String is an Object, not a primitive type. Second, primitives can't be null (primitives are ints, doubles, floats, chars, booleans and some others). Now, if you encounter a parameter which is null and it shouldn't be null (in other words you received an illegal argument) you have some choices:
- Throw an IllegalArgumentException indicating the parameter is null and your method expects it not to be null.
- Don't do anything. Assume your method is being used correctly (in other words, assume no programmer errors).
- Use assertions:
assert(x != null);
I personally am not a fan of defensive programming and usually prefer the second option. But still, if I want to ensure some invariants on my variables I'm using assertions. But these are just my habits and others probably disagree.
Related Topics
No Exception While Type Casting with a Null in Java
Replacing If Else Statement with Pattern
How to Bind an Object List with Thymeleaf
Performance Concurrenthashmap VS Hashmap
How to Create a Class Literal of a Known Type: Class<List<String>>
How to Pass a Variable from One Thread Group to Another in Jmeter
Could Not Find Method Compile() for Arguments Gradle
Comparing and Thencomparing Gives Compile Error
How to Abort a Thread in a Fast and Clean Way in Java
Hibernate Sessionfactory VS. JPA Entitymanagerfactory
Performance Considerations for Keyset() and Entryset() of Map
Transform Java Future into a Completablefuture
What's the Default Value of Char
What Is the Best/Simplest Way to Read in an Xml File in Java Application
How to Deserialize Js Date Using Jackson