I use x != null to avoid NullPointerException. Is there an alternative? if (x != null) { // ... }
Home/avoid
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on retRead more
This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don’t know or don’t trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on returning nulls to indicate something thus requiring the caller to check for nulls.
To put this another way, there are two instances where null checking comes up:
(2) is easy. As of Java 1.7 you can use
Objects.requireNonNull(foo)
. (If you are stuck with a previous version thenassert
ions may be a good alternative.)“Proper” usage of this method would be like below. The method returns the object passed into it and throws a
NullPointerException
if the object is null. This means that the returned value is always non-null. The method is primarily intended for validating parameters.It can also be used like an
assert
ion though since it throws an exception if the object is null. In both uses, a message can be added which will be shown in the exception. Below is using it like an assertion and providing a message.Generally throwing a specific exception like
NullPointerException
when a value is null but shouldn’t be is favorable to throwing a more general exception likeAssertionError
. This is the approach the Java library takes; favoringNullPointerException
overIllegalArgumentException
when an argument is not allowed to be null.(1) is a little harder. If you have no control over the code you’re calling then you’re stuck. If null is a valid response, you have to check for it.
If it’s code that you do control, however (and this is often the case), then it’s a different story. Avoid using nulls as a response. With methods that return collections, it’s easy: return empty collections (or arrays) instead of nulls pretty much all the time.
With non-collections it might be harder. Consider this as an example: if you have these interfaces:
where Parser takes raw user input and finds something to do, perhaps if you’re implementing a command line interface for something. Now you might make the contract that it returns null if there’s no appropriate action. That leads the null checking you’re talking about.
An alternative solution is to never return null and instead use the Null Object pattern:
Compare:
to
which is a much better design because it leads to more concise code.
That said, perhaps it is entirely appropriate for the findAction() method to throw an Exception with a meaningful error message — especially in this case where you are relying on user input. It would be much better for the findAction method to throw an Exception than for the calling method to blow up with a simple NullPointerException with no explanation.
Or if you think the try/catch mechanism is too ugly, rather than Do Nothing your default action should provide feedback to the user.
See less