Whenever I had to check if the given parameters to a method are not null, I used to write a null check and throw a IllegalArgumentException
if the null check fails:
if (user == null) {
throw new IllegalArgumentException("User can't be null.");
}
However, by reading the source code of some Java 8 classes such as ArrayList
, I found out that Oracle are using Objects.requireNonNull
to check a parameter against a null value, and then, if the test fails, a NullPointerException
is thrown.
This way, the earlier code snippet should look like this by adopting this approach:
Objects.requireNonNull(user, "User can't be null.");
Smaller and more readable.
Assuming that I have control of the whole exception handling of the system, (even that I shouldn't, sometimes it is part of the business to handle these unchecked exceptions), should I replace my IllegalArgumentException
with NullPointerException
and use Objects.requireNonNull
instead of writing my own null checking and exception throwing?
Using Objects.requireNonNull(c)
is a very elegant way to check if the element is not null. But there is an interesting discussion about whether choosing NullPointerException
or IllegalArgumentException
--> IllegalArgumentException or NullPointerException for a null parameter?. So throwing NullPointerException
is the java way to express that a reference is null.
Otherwise, you can make your own method requireNotNull()
. It is simple :
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
and you can change the exception NullPointerException
by IllegalArgumentException
.
There is a discussion of what kind of exception should be thrown when a method receives a null value it doesn't expect. Some people argue for NullPointerException
, some people argue for IllegalArgumentException
. The JDK way seems to be to throw NullPointerException
in such cases, which is why the Objects.requireNonNull
throws it.
But I wouldn't modify existing code just because of this method, although you might want to consider using Objects.requireNonNull
in new code. (Using it in generally makes code more readable than to check for null and throw an exception manually.)