views:

45412

answers:

25

I work with java all day long. The most used idiom (code snippet) I'm programing in java, is to test if an object != null before I use it, to avoid a NullPointerException of course. But the code looks very ugly and becomes unreadable.

Is there a good alternative to avoid this code snippet?

Update: Pan, I was not clear with my question. I want to adress the necessity to test every object if you want to access a field or method of this object. For example:

...
if (someobject != null)
{
    someobject.doCalc();
}
...

in case I want avoid NullPointerException and didn't know exactly that the object can't be null. So my code get splattered with these tests.

Nevertheless thanks a lot for your answers, I got a bunch of new insight.

+2  A: 

Look at "Null Object" pattern.

TcKs
+45  A: 

Null Object pattern.

geeeeeeeeeek
Be careful of the situations in which the Null Object Pattern is applied. Overusing it, or using it under the wrong conditions will cause more headaches than your check for null.
Robin
I agree - if Java were like Smalltalk (where `nil` actually is an object) then this is fine. In practice I have found that you don't always create `Null` instances because of the overhead: so there ends up being an amount of confusion between whether you are expecting `null` or `NullObject` back
oxbow_lakes
A null instance is going to be immutable, so you only need to create one.
Tom Hawtin - tackline
+2  A: 

Null Objects

Rik
+2  A: 

You can use the Null Object design pattern.

Fredrik Kalseth
+8  A: 

Rather than Null Object Pattern -- which has its uses -- you might consider situations where the null object is a bug.

When the exception is thrown, examine the stack trace and work through the bug.

Jim Nelson
Problem is that usually you loose context as the NullPointerException does not indicate WHICH variable was null, and you may have several "."-operations on the line.Using "if (foo == null) throw new RuntimeException("foo == null")" allows you to state explicitly WHAT was wrong, giving your stack trace much more value to those who have to fix it.
Thorbjørn Ravn Andersen
+15  A: 
  • If you consider an object should not be null (or it is a bug) use an assert.
  • If your method doesn't accept null params say it in the javadoc and use an assert.

You have to check for object != null only if you want to handle the case where the object may be null...

There is a proposal to add new annotations in Java7 to help with null / notnull params: http://tech.puredanger.com/java7/#jsr308

pgras
+5  A: 

sometimes, you have methods that operate on its parameters that define a symmetric operation: a.f(b); <-> b.f(a);

if you know b can never be null, you can just swap it. most useful for equals: instead of foo.equals("bar"); better do "bar".equals(foo);

Johannes Schaub - litb
+8  A: 

Depending on what kind of objects you are checking you may be able to use some of the classes in the apache commons such as: apache commons lang and apache commons collections

Example:

String foo;
...
if( StringUtils.isBlank( foo ) ) {
   ///do something
}

or (depending on what you need to check):

String foo;
...
if( StringUtils.isEmpty( foo ) ) {
   ///do something
}

The StringUtils class is only one of many; there are quite a few good classes in the commons that do null safe manipulation.

javamonkey79
Also you can use the more generic version from Apache Commons, quite useful at the start of methods to check params I find. Validate.notNull( object, "object must not be null");http://commons.apache.org/lang/apidocs/org/apache/commons/lang/Validate.html
monojohnny
+17  A: 

If null-values is not allowed

If your method called externally, start with something like this:

public void method(Object object) {
  if (object == null) {
    throw new IllegalArgumentException("...");
  }

In the rest of that method, you know that it's not null.

If it is an internal method (not part of an api), just document that it cannot be null, and that's it. Example:

public String getFirst3Chars(String text) {
  return text.subString(0, 3);
}

However, if your method just passes the value on, and the next method passes on etc. it could get problematic. In that case you may want to check the argument as above.

If null is allowed

This really depends. If find that I often do something like this:

if (object == null) {
  // something
} else {
  // something else
}

So I branch, and do two completely different things. There is no ugly code snippet, because I really need to do two different things depending on the data. For example, should I work on the input, or should I calculate a good default value?


It's actually rare for me to use the idiom "if (object != null && ...".

It may be easier to give you examples, if you show examples of where you typically use the idiom.

myplacedk
+3  A: 

Asking that question points out that you may be interested in error handling strategies. Your team's architect should decide how to work errors. There are several ways to do this:

  1. allow the Exceptions to ripple through - catch them at the 'main loop' or in some other managing routine.

  2. check for error conditions and handle them appropriately

Sure do have a look at Aspect Oriented Programming, too - they have neat ways to insert if( o == null ) handleNull() into your bytecode.

xtofl
A: 

Wherever you pass an array or a Vector, initialise these to empty ones, instead of null. - This way you can avoid lots of checking for null and all is good :)

public class NonNullThing {

Vector vectorField = new Vector();

int[] arrayField = new int[0];

public NonNullThing() {

  // etc

}

}

+112  A: 

This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on returning nulls to indicate something thus requiring the caller to check for nulls.

To put this another way, there are two instances where null checking comes up:

  1. Where null is a valid response in terms of the contract; and

  2. Where it isn't a valid response.

(2) is easy. Either use asserts or let it fail. Asserts are a highly underused Java feature that was added in 1.4. The syntax is:

assert *<condition>*

or

assert *<condition>* : *<object>*

where <object>'s toString() output will be included in the error.

Assert throws an Error (AssertionError) is the condition is not true. By default, Java ignores asserts. You can enable the feature by passing the option -ea to the JVM. Its also more sophisticated than that where you can enable and disable asserts for individual classes and packages. This means that you can validate code with the asserts while developing and testing and disable them in a production environment although my testing has shown next to no performance impact from asserts.

Not using asserts in this case is OK because the code will just fail, which is what will happen if you use asserts. The only difference is that with asserts it might happen sooner, in a more meaningful way and possibly with extra information for you to figure out why it happened if you weren't expecting it.

(1) is a little harder. If you have no control over the code you're calling then you're stuck. If null is a valid response, you have to check for it.

If its code you do have control over however (and this is often the case) then its a different story. Avoid using nulls as a response. With methods that return collections, it's easy: return empty collections or arrays over nulls pretty much all the time.

With non-collections it might be harder. Consider this as an example: if you have this interfaces:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

where Parser takes raw user input and finds something to do, perhaps if you're implementing a command line interface for something. Now you might make the contract that it returns null if theres no appropriate action. That leads the null checking you'er talking about.

An alternative solution is to never return null and instead do something like this:

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

Compare:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.getAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

to

ParserFactory.getParser().findAction(someInput).doSomething();

which is a much better design because it leads to more concise code.

cletus
I disagree with your statements for the DO_NOTHING action. If the find action method cannot find an action, then returning null is the right thing to do. You've "found" an action in your code which isn't really found, which violates the principle of the method, to find a useable action.
MetroidFan2002
If you ship a library, and want to enable assertions by force, you can use fa.jarSee http://smallwiki.unibe.ch/adriankuhn/javacompiler/forceassertions/
Adrian
I agree that null is overused in Java, especially with lists. So many apis would be better if they return an empty list/array/collection instead of null.Many times, null is used where an exception should be thrown instead. An exception should be thrown if the parser can't parse.
Laplie
very insightful, thank you!
javamonkey79
In your 'getParser' example, I think I would argue that an exception should have been thrown if 'null' was going to be returned unless you can somehow construct a valid argument for why returning null is NOT an 'exceptional' case.
imaginaryboy
I think it should be possible in the source code to specify that null is never returned from method X and that a given parameter should NOT be null and it is an error to pass one.
Thorbjørn Ravn Andersen
The latter example here is, IIRC, the Null Object design pattern.
SnOrfus
Assertion is good for TESTING. It's dangerous to use on PROD.
ZiG
I disagree with DO_NOTHING because although it eliminates that null check, the resultant behaviour is unexpected. If null is an unexpected input to your method then it is pertinent that your method throws NPE so that the caller is aware and things are logged(A fail fast behaviour). With using DO_NOTHING, its like everything passed but the resultant action didnt take place and users will redo the action (resubmitting the form). I agree to return empty lists, objects but not nulls as return values but dont agree to the DO_NOTHING illustrated above. But NPE's shouldnt display stacktrace on UI
Cshah
@Cshah (and MetroidFan2002). Simple, put that into the contract and then it is clear that a non-found returned action will do nothing. If this is important information to the caller, then provide a way to discover that it was a non-found action (i.e. provide a method to check if the result was the DO_NOTHING object). Alternatively, if action should normally be found then you still should not return null but instead throw an exception specifically indicating that condition - this still results in better code. If desired, provide a separate method returning boolean to check if action exists.
Kevin Brock
+2  A: 

Only for this situation - Avoiding checking for null before a string compare:

if ( foo.equals("bar") ) { // ... }

will result in a NullPointerException if foo doesn't exist.

You can avoid that if you compare your Strings like this:

if ( "bar".equals(foo) ) { // ... }

echox
A: 

I've tried the NullObjectPattern but for me is not always the best way to go. There are sometimes when a "no action" is not appropiate.

NullPointerException is a Runtime exception that means it's developers fault and with enough experience it tells you exactly where is the error.

Now to the answer:

Try to make all your attributes and its accessors as private as possible or avoid to expose them to the clients at all. You can have the argument values in the constructor of course, but by reducing the scope you don't let the client class pass an invalid value. If you need to modify the values, you can always create a new object. You check the values in the constructor only once and in the rest of the methods you can be almost sure that the values are not null.

Of course, experience is the better way to understand and apply this suggestion.

Byte!

OscarRyz
+3  A: 

The google collections framework offers a good and elegant way to achieve the null check.

There is a method in a library class like this:

static <T> T checkNotNull(T e){
   if(e == null){
      throw new NullPointerException();
   }
   return e;
}

And the usage is (with import static):

...
void foo(int a, Person p){
   if(checkNotNull(p).getAge() > a){
      ...
   }else{
      ...
   }
}
...

or in your example:

checkNotNull(someobject);
someobject.doCalc();
damian
mmm, what is the difference? p.getAge() would throw the same NPE with less overhead and a clearer stack trace. What am I missing?
mysomic
It is better to throw an IllegalArgumentException("e == null") in your example as it clearly indicates that it is a programmer-intended exception (along with enough information to actually allow the maintainer to identify the problem). NullPointerExceptions should be reserved for the JVM, as it then clearly indicates that this was unintentional (and usually happens somewhere hard to identify)
Thorbjørn Ravn Andersen
+6  A: 
erickson
I think this is wrong. There should be a way to specify that a given variable is ALWAYS non-null.
Thorbjørn Ravn Andersen
Update: the proposal will not make Java7. See http://blogs.sun.com/darcy/entry/project_coin_final_five .
Boris Terzic
A: 

if ( "bar".equals(foo) ) { // ... } i do agree with this. because you get the string not the parameter which is we do not know about the value.

+3  A: 

Ultimately, the only way to completely solve this problem is by using a different programming language:

  • In Objective-C, you can do the equivalent of invoking a method on nil, and absolutely nothing will happen. This makes most null checks unnecessary but can make errors much harder to diagnose.
  • In Nice, a Java-derivated language, there are two versions of all types: a potentially-null version and a not-null version. You can only invoke methods on not-null types. Potentially-null types can be converted to not-null types through explicit checking for null. This makes it much easier to know where null checks are necessary and where they aren't.
Michael Borgwardt
Woah... The most correct answer and its gets downvoted, where's the justice? In Java null is *always* a valid value. It's the corollary to Everything is an Object - Null is an Everything (of course we're ignoring primitives here but you get the idea). Personally I favour the approach taken by Nice, though we could make it so that methods can be invoked on nullable types and promote NPEs to checked exceptions. This would have to be done via a compiler switch though as it would break all existing code :(
CurtainDog
+5  A: 

If you can, consider using Scala, it introduces the Option Pattern (may be familiar from functional languages) for this.

thSoft
+1 On Scala, although in the tutorial Option is not a monad.
volothamp
+5  A: 

If you use (or planning to use) JetBrains Idea, a Java ide, you can use some particular annotations developed by them.

Basically, you've got:

@Nullable

and

@NotNull

You can use in method and parameters, like this:

@NotNull public static String helloWorld() {
    return "Hello World";
}

or

@Nullable public static String helloWorld() {
    return "Hello World";
}

The second example won't compile (in Idea).

When you use the first HelloWorld() function in another piece of code:

public static void main(String[] args)
{
    if(helloWorld() != null) {
        System.out.println(helloWorld());
    } 
}

Now the idea compiler will tell you that the check is useless, since the HelloWorld() function won't return null, ever.

Using parameter

void someMethod(@NotNull someParameter) { }

if you write something like:

someMethod(null);

This won't compile.

Last example using @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Doing this

iWantToDestroyEverything().something();

And you can be sure that this won't happen. :)

It's a nice way to let the compiler check something more than it usually does and to enforce your contracts to be stronger. Unfortunately, it's not supported by all the compilers.

volothamp
A brilliant solution! Thumbs up for JetBrains :-)
Thrawn
`@NotNull`, `@Nullable` and other nullness annotations are part of [JSR 305](http://jcp.org/en/jsr/detail?id=305). You can also use them to detect potential problems with tools like [FindBugs](http://findbugs.sourceforge.net/).
Jacek S
A: 

Check this - DefaultIfNull from Apache ObjectUtils.

Padmarag
A: 

My answer is: For utility classes, you can check that parameters are not null. In all other cases you may not have to . use encapsulation as much as possible, thus reducing the places you feel tempted to check for null.

daniel
+1  A: 

In addition to using assert you can use the following :

if (someobject == null) {
    // handle null here then move on.
}

This is slightly better than :

if (someobject != null) {
    .....
    .....



    .....
}
fastcodejava
Mh, why that? Please don't feel any defensive, I'd just like to learn more about Java :)
Mudu
+1  A: 

This comes from a lazy programmer. Isn't there a tool which goes through the entire code and puts in null checks wherever required. In that case we as programmers need not worry about that which coding. I can also find and replace using regex but just wanted to check if there is a tool available which has been tried and tested.

jeets
A: 
public static <T> T ifNull(T toCheck, T ifNull){
       if(toCheck == null){
           return ifNull;
       }
       return toCheck;
}
tltester