0

Consider a method with objects as parameters. Is it a good practice to check object as not null within method or should I check it before calling that method. I am feeling that if someone is using the method later, if they pass null for a parameter, the method will fail to convey what it is missing. Please suggest the best one from the below methods.

Method 1:

void method(Object obj1, Object obj2)
{
  if(obj1!=null && obj2!=null
  {}
}

Method 2:

void method(Object obj1, Object obj2)
{
  //logic
}

Method 3:

void method(Object obj1, Object obj2)
{
  if(obj1 ! =null && obj2 !=null)
  {//logic}

  throw exception();
}
Andy Turner
  • 137,514
  • 11
  • 162
  • 243
ksv
  • 67
  • 8
  • In public APIs I always do something like `Objects.requireNotNull(obj1, "obj1 must not be null")`. – lexicore May 09 '18 at 18:49
  • 2
    Have a rule, and stay consistent. Mine is to check all input parameters inside public functions, and never within private methods. So when I find myself performing null validation outside the same function call over and over again, it's time to redesign. – Timir May 09 '18 at 18:50
  • @lexicore an important point about your suggestion is that you will know exactly what is wrong: if you throw an exception because obj1 is null or ob2 is null, you don't know which, and that makes debugging harder. – Andy Turner May 09 '18 at 18:51
  • @AndyTurner I got called paranoid for this more than once. – lexicore May 09 '18 at 18:54
  • You solve this by documenting what the requirement is for each parameter and what will happen if that requirement isn’t met – Joakim Danielson May 09 '18 at 18:55
  • use `Optional>` for arguments that can be null and either check for null on arguments that are not permitted to be null (and throw an exception if they are null; perhaps IllegalArgumentException) or don't check for null and accept that it will sometimes throw NullPointerException. In either case (on the ilegally null side) write a junit case that tests the expected outcome of passing a null. – DwB May 09 '18 at 19:06
  • @DwB Optional is not meant to be used as a method parameter. https://stackoverflow.com/questions/31922866/ – killjoy May 09 '18 at 19:21
  • @killjoy `Optional` is designed to represent "maybe something is there". While it is not a good practice to use it as a method parameter, the "intent" of `Optional` is unclear from the JavaDoc. – DwB May 09 '18 at 19:48

2 Answers2

1

There is a few things you could do in this situation. The first thing I suggest doing is using jsr305 findbugs or similar (@Nullable and@Nonnull) to explicitly mark a parameter or method as accepting or returning null. If you have your IDE configured properly, it will know about these and try to prevent null pointers.

public void foo(@Nonnull Bar bar) {

Another thing you can do is throw an IllegalArgumentException if the parameter is null when you asked for nonnull. This will crash the application and the blame will be on the developer.

    if (bar == null) throw new IllegalArgumentException("bar cannot be null");

There are a few libraries that have methods for this. e.g. Guava's Preconditions and Commons-Lang's Validate. They also have method for other validations, such as range and states.

Java 8 also has a method Objects.requireNonNull()

    Objects.requireNonNull(bar);
    Preconditions.checkNotNull(bar);
    Validate.notNull(bar);
killjoy
  • 3,665
  • 1
  • 19
  • 16
-2

Checking argument for being null prior to passing it to a method is something that must be addressed on the client side.

Regarding best practices for method writing: I believe it is a good practice to take no assumptions on validity of passed parameters. You should throw IllegalArgumentException if your method cannot operate with null arguments passed.

  • 2
    Don't rely upon calling code to enforce your preconditions. If it matters to your code, check it in your code. – Andy Turner May 09 '18 at 18:52