Should we always check each parameter of method in java for null in the first line?

25,141

Solution 1

The best way is to only check when necessary.

If your method is private, for example, so you know nobody else is using it, and you know you aren't passing in any nulls, then no point to check again.

If your method is public though, who knows what users of your API will try and do, so better check.

If in doubt, check.

If the best you can do, however, is throw a NullPointerException, then may not want to check. For example:

int getStringLength(String str) {
  return str.length();
}

Even if you checked for null, a reasonable option would be throwing a NullPointerException, which str.length() will do for you anyways.

Solution 2

No. It's standard to assume that parameters will not be null and that a NullPointerException will be thrown otherwise. If your method allows a parameter to be null, you should state that in your api.

Solution 3

It's an unfortunate aspect of Java that references can be null and there is no way to specify in the language that they are not.

So generally yes, don't make up an interpretation for null and don't get into a situation where an NPE might be thrown later.

JSR305 (now inactive) allowed you to annotate parameters to state that they should not be given nulls.

void fn(@Nonnull String a, @Nonnull Integer b, @Nonnull Object c) {

Verbose, but that's Java for you. There are other annotation libraries and checkers that do much the same, but are non-standard.

(Note about capitalisation: When camel-casing words of the form "non-thing", the standard is not to capitalise the route word unless it is the name of a class. So nonthing and nonnull.)

Annotations also don't actually enforce the rule, other than when a checker is run. You can statically include a method to do the checking:

public static <T> T nonnull(T value) {
    if (value == null) {
        throwNPE();
    }
    return value;
}
private static void throwNPE() {
    throw new NullPointerException();
}

Returning the value is handy in constructors:

import static pkg.Check.nonnull;

class MyClass {
    @Nonnull private final String thing;
    public MyClass(@Nonnull String thing) {
        this.thing = nonnull(thing);
    }
    ...

Solution 4

I don't see a great deal of point in doing this. You're simply replicating behaviour that you'd get for free the first time you try to operate on a, b or c.

Solution 5

Yes, public methods should scrub the input, especially if bad input could cause problems within your method's code. It's a good idea to fail fast; that is, check as soon as possible. Java 7 added a new Objects class that makes it easy to check for null parameters and include a customized message:

public final void doSomething(String s)
{
  Objects.requireNonNull(s, "The input String cannot be null");
  // rest of your code goes here...
}

This will throw a NullPointerException.

Javadocs for the Objects class: http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html

Share:
25,141
Sanjeev Kumar Dangi
Author by

Sanjeev Kumar Dangi

Updated on October 20, 2020

Comments

  • Sanjeev Kumar Dangi
    Sanjeev Kumar Dangi over 3 years

    Every method accepts a set of parameter values. Should we always validate the non-nullness of input parameters or allow the code to fail with classic RunTimeException?

    I have seen a lot of code where people don't really check the nullness of input parameters and just write the business logic using the parameters. What is the best way?

    void public( String a, Integer b, Object c)
    {
      if( a == null || b == null || c == null)
      {
        throw new RunTimeException("Message...");
      }
      .....business logic.....
    }