Is it bad style to use NullPointerException to test for null? [closed]

问题

I have some code along the following pattern:

return a().b().c().d().e();

now since every one of those methods could return null, one would usually test for this:

if( (a()!=null) && (a().b() != null) && ....) {
   return a().b().c().d().e();
} else  {
  return null;
}

(and maybe use some local variables to avoid duplicate calls)

I'm tempted to do:

try {
   return a().b().c().d().e();
} catch (NullPointerException e) {
   return null;
}

Is that considered bad style? inefficient? Or quite ok?

回答1:

Don't do this. Throwing and catching exceptions is fairly expensive when compared to basic null checks.

You might also be interested to know that syntax has been proposed for a future version of Java that would make this simpler. It would go something like this:

a()?.b()?.c()?.d()

The "?." operation would be an optional version of the "." operator. If LHS is null, it would return null at that point instead of trying to evaluate RHS. Exactly what you are looking for, but I am afraid it didn't make the cut for Java 7. Don't know the status of this feature for Java 8.

回答2:

It's considered bad style because exceptions are supposed to represent exceptional conditions, things that aren't likely to come up during normal execution and that indicate that something has gone wrong. Using exceptions to check whether objects are null uses this machinery to check for more mundane failures. As mentioned by Konstantin's post, there's also a runtime penalty for using exceptions. Also, wrapping all of the errors up in a single NullPointerException means that you lose the information about what in particular went wrong. Which function returned null? Was that due to normal errors, or is there something more serious going on?

There are other options you haven't considered here. Rather than having a(), b(), etc. return null to signal an error, consider having them throw more detailed exceptions explaining why they can't return something. If they're failing because a network connection drop, have them throw IOExceptions or something of the like. If they're failing because you have a bad index into an array, make that clear as well.

In short, if you want to use exceptions, use them to more precisely notify the rest of the program what happened. That way, you can take more fine-grained corrective action.

回答3:

Generally, this line of code would be bad by itself, ignoring the null issue. See the "Law of Demeter" or "Principle of Least Knowledge".

return a().b().c().d().e();

If I had no control over a, b, c, d, and e, I would rewrite the following.

if( (a()!=null) && (a().b() != null) && ....) {
   return a().b().c().d().e();
} else  {
  return null;
}

as this, which is still heinous but way more useful when something messes up and I need to read a stack trace.

B b = a.a();
if(b == null)
{
   return null;
}

C c = b.b();
if(c == null)
{
   return null;
}

D d = c.c();
if(d == null)
{
   return null;
}

return d.d();

No, catching NullPointerException is not an appropriate thing to do. That is kind of like wrapping a for loop in a try block to catch ArrayIndexOutOfBoundsException.

If this is supposed to be a fluent API where chaining is a strength and goal then it should never be returning nulls.

回答4:

I wouldn't do that mainly because what if a() or b() or c() etc have a bug that causes them to throw NullPointerException? In that case you're catching it and moving on when you shouldn't have.

回答5:

Change the methods so they don't return null or avoid chaining methods that can return null.

回答6:

Instead of returning null, let each of them return NullObject or something. Read about Null Object Pattern.

来源：https://stackoverflow.com/questions/4778439/is-it-bad-style-to-use-nullpointerexception-to-test-for-null

标签

java

coding-style

nullpointerexception