should I pay much attention on NullPointerException?

Question

when I use the JUnit test to check my coding process，I find there are some problems bother me. for example:

List<User> list = userDao.findBy("id",id);
list.get(0).getName();

there is the problem.I didn't use any assert to check the list is not null before using it which may cause NullPointException.but look at the business logic.

When I create a new User like this.

if(user!=null){
   userDao.save(user)
}

It should be not null.because I check the user is not null when I add one, so I definitely know the user was successful in the database.

if I add a lot of this when I get the user：

if(list!=null||list.size()>0){...};

in the similar place that makes the code into chaos.

should I add it or not?how to make a choice? thx anyway.

I think No you shouldn't because unit test test that the logic of the block of code is working as expecting, you should check that just in your code — Fady Saad, Apr 07 '17 at 02:29
sorry, I didn't express it clearly, I mean when I write the JUnit test, I find my code has the problem, not int the unit test code — kevin, Apr 07 '17 at 02:32
Yes, I got it, Just use precondition and check that in the precondition — Fady Saad, Apr 07 '17 at 02:35
This should help relative to allowing fields to be null, which should generally be avoided: [Avoiding != null statements](http://stackoverflow.com/questions/271526/avoiding-null-statements). You ought to be able to avoid the defensive checking of null. — 65Roadster, Apr 07 '17 at 02:47

domsson · Accepted Answer · 2017-04-07T03:02:24.623

I think what you are looking for are method preconditions or, more generally, contracts.

Let's assume your code is split up into many small methods, as it should be. Then you define preconditions and postconditions for every method. These need to be met, otherwise failure is to be expected. If you do this consistently, the question of where to put these checks will pretty much answer itself in quite an intuitive way.

As an example, let's consider two ways you could write a method that does something with a User:

private void doSomethingWithUser(User u) {
  if (u == null) {
    /* take appropriate steps */
  }
  /* perform some action on the user object */
}

Above, the method takes care of the null-check. Hence, there is no need for the calling code to do it.

/* 
 * Does this and that with the User.
 * Precondition: the User `u` may not be null!
 */
private void doSomethingWithUser(User u) {
    /* perform some action on the user object */
}

Here, the method does not check u for null, but reading the comment, we can see that this is how the method was designed. It is the responsibility of the calling code to hand in a non-null object, else the behavior will be undefined.

Of course, now you face the decision of when to go with which of these. And obviously, you can set preconditions for your methods and have them still perform appropriate checks. They could then return a value that indicates an error or throw an Exception, as is pretty common.

EDIT:

but if there are lots of objects need to check before I use them?should I check them all?

Consider this:

public class SimpleClass {
  public static void main (String[] args) {
    User sware = new User("sware");
    User domdom = new User("domdom");

    doSomethingWithUser(sware);
    doSomethingWithUser(domdom);
  }
}

Here, we are declaring and initializing two objects in the main method. We know they are not null. We then use them right away. No matter if that method checks for null or not, I would not perform such a check outside - there is just no way those objects would be null.

Now, imagine we have a much more complex code:

public class VeryComplexClass extends ComplexClass implements ComplexInterface {
  /* ... */
  @Override
  private boolean doSomethingWithUser(User u) {
    if (u == null) {
         return false;    
    }
    /* ... */
  }
}

Let's say we need to implement the doSomethingWithUser() method to satisfy the interface. Or the method comes from the parent class and we override it. We don't know where u will be coming from. Who could potentially call this method? A user from the outside of the class? Or is this method being used by the class itself? Will it be called with a member being passed in? It is pretty hard to tell at this point. Hence, I would recommend to put a null check into place.

I really depends on your code and also how paranoid you are. If you declare and initialize some object and then use it, I don't see a reason why you should check for null. Once you start handing objects around, however, it can soon become rather confusing where that object came from or where it might have been manipulated. It would then make sense to perform checks on it accordingly. — domsson, Apr 07 '17 at 02:48
Updated the answer with some weird example. Hope it makes sense. — domsson, Apr 07 '17 at 03:02

score 0 · Answer 2 · answered Apr 07 '17 at 02:36

0

As you have already checked the user for being null, I dont see the need for you to worry about NullPointerException..Just go ahead with that code

answered Apr 07 '17 at 02:36

viraj nilakh

73
1
1
6

should I pay much attention on NullPointerException?

2 Answers2