4414

I use x != null to avoid NullPointerException. Is there an alternative?

if (x != null) {
    // ...
}
12
  • 144
    @Shervin Encouraging nulls makes the code less understandable and less reliable. Aug 2, 2010 at 9:17
  • 85
    Not using null is superior to most other suggestions here. Throw exceptions, don't return or allow nulls. BTW - 'assert' keyword is useless, because it's disabled by default. Use an always-enabled failure mechanism
    – ianpojman
    Jun 8, 2012 at 19:40
  • 8
    Nulls should be avoided in high-level code. Tony Hoare, who invented null references, calls them "a billion-dollar mistake". Take a look here for some ideas. Apr 4, 2016 at 13:05
  • 4
    Seems to be in Java 8: static Objects.isNull(Object o) docs.oracle.com/javase/8/docs/api/java/util/Objects.html Jun 23, 2016 at 17:02
  • 10
    The most common misuse of null is people returning null instead of an empty collection. That drives me crazy each time. Stop using nulls, and you'll live in a better world. Also, spread your code with final keyword and you'll live in a even better world.
    – Jack
    Jun 29, 2021 at 9:22

69 Answers 69

2863

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. As of Java 1.7 you can use Objects.requireNonNull(foo). (If you are stuck with a previous version then assertions may be a good alternative.)

"Proper" usage of this method would be like below. The method returns the object passed into it and throws a NullPointerException if the object is null. This means that the returned value is always non-null. The method is primarily intended for validating parameters.

public Foo(Bar bar) {
    this.bar = Objects.requireNonNull(bar);
}

It can also be used like an assertion though since it throws an exception if the object is null. In both uses, a message can be added which will be shown in the exception. Below is using it like an assertion and providing a message.

Objects.requireNonNull(someobject, "if someobject is null then something is wrong");
someobject.doCalc();

Generally throwing a specific exception like NullPointerException when a value is null but shouldn't be is favorable to throwing a more general exception like AssertionError. This is the approach the Java library takes; favoring NullPointerException over IllegalArgumentException when an argument is not allowed to be null.

(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 it's code that you do control, however (and this is often the case), then it's a different story. Avoid using nulls as a response. With methods that return collections, it's easy: return empty collections (or arrays) instead of nulls pretty much all the time.

With non-collections it might be harder. Consider this as an example: if you have these 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 there's no appropriate action. That leads the null checking you're talking about.

An alternative solution is to never return null and instead use the Null Object pattern:

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.findAction(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.

That said, perhaps it is entirely appropriate for the findAction() method to throw an Exception with a meaningful error message -- especially in this case where you are relying on user input. It would be much better for the findAction method to throw an Exception than for the calling method to blow up with a simple NullPointerException with no explanation.

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

Or if you think the try/catch mechanism is too ugly, rather than Do Nothing your default action should provide feedback to the user.

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}
3
  • 7
    Nice answer, especially mentioning asserts. I came from C and use them constantly. As to Null Objects, they are NOT a silver bullet. I have often spent hours debugging code which turned out to be a Null Object being used, doing nothing (or returning its defaults) when a NPE would have been indicated the problem much more clearly. So then you'll have to do a "Null Object check" instead of a null check, and haven't won anything, actually lost clarity. Nowadays, if I can't avoid null, I just document it clearly and that's it.
    – Franz D.
    Dec 25, 2021 at 0:01
  • Writing this.bar = Objects.requireNonNull(bar); is a good use of this method, because you're not about to use this.bar. This way, you get the exception when an invalid null object is being passed, rather than when you try to use it. But, it often gets used this way: Objects.requireNonNull(getThing()).doThingStuff(); Here, the call to Objects.requireNonNull() doesn't change the behavior at all, it throws the NPE either way. It is best used when you are saving an object for later use. In my second example, the exception is useful. It helps track down the bug. Jul 9, 2022 at 3:45
  • 2
    Should we suggest using exceptions for control flow though? While it's technically a solution that works, programmers should remember that exceptions should only be used to catch unexpected situations. When validating a user's input, invalid input should ideally not lead to exceptions being thrown.
    – Lee White
    Jul 12, 2022 at 12:34
716

If you use (or planning to use) a Java IDE like JetBrains IntelliJ IDEA, Eclipse or Netbeans or a tool like findbugs then you can use annotations to solve this problem.

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 IntelliJ IDEA).

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

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

Now the IntelliJ 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.

In IntelliJ IDEA 10.5 and on, they added support for any other @Nullable @NotNull implementations.

See blog post More flexible and configurable @Nullable/@NotNull annotations.

16
  • 134
    @NotNull, @Nullable and other nullness annotations are part of JSR 305. You can also use them to detect potential problems with tools like FindBugs.
    – Jacek S
    May 8, 2010 at 16:33
  • 37
    I find it strangely annoying that the @NotNull & @Nullable interfaces live in the package com.sun.istack.internal. (I guess I associate com.sun with warnings about using a proprietary API.)
    – Jonik
    Jun 30, 2011 at 23:33
  • 22
    code portability goes null with jetbrains.I would think twice(square) before tying down to ide level.Like Jacek S said they are part of JSR any way which I thought was JSR303 by the way. Sep 8, 2011 at 9:39
  • 14
    I really don't think that using a custom compiler is a viable solution to this problem. Aug 19, 2012 at 8:24
  • 71
    The good thing about annotations, which @NotNull and @Nullable are is that they nicely degrade when the source code is built by a system that doesn't understand them. So, in effect, the argument that the code is not portable may be invalid - if you use a system that supports and understands these annotations, you get the added benefit of stricter error checking, otherwise you get less of it but your code should still build fine, and the quality of your running program is THE SAME, because these annotations were not enforced at runtime anyway. Besides, all compilers are custom ;-) Mar 20, 2013 at 9:49
354

If null-values are not allowed

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

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

Then, in the rest of that method, you'll know that object is 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 it 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.

13
  • 102
    What's the point in throwing IllegalArgumentException? I think NullPointerException would be clearer, and that would also be thrown if you don't do the null-check yourself. I'd either use assert or nothing at all.
    – Axel
    Aug 9, 2011 at 16:47
  • 24
    It's unlikely that every other value than null is acceptable. You could have IllegalArgumentException, OutOfRageException etc etc. Sometimes this makes sense. Other times you end up creating a lot of exception classes that doesn't add any value, then you just use IllegalArgumentException. It doesn't makes sense to have one exception for null-input, and another one for everything else.
    – myplacedk
    Aug 15, 2011 at 12:26
  • 8
    A security hole? The JDK is full of code like this. If you don't want the user to see stacktraces, then just disable them. No one implied that the behaviour is not documented. MySQL is written in C where dereferencing null pointers is undefined behaviour, nothing like throwing an exception.
    – fgb
    Apr 8, 2013 at 0:39
  • 9
    throw new IllegalArgumentException("object==null") Apr 20, 2013 at 23:35
  • 8
    1/2 I have to agree that a IllegalArgumentException is better than a plain-vanilla NPE for these type of situations. I see a NPE as an indication that somewhere in the code, something unsafely de-referenced an expression that happened to be null (assuming all known and declared preconditions and invariants were met). An illegal argument exception OTH tells me a well-known precondition or invariant was not met. Aug 12, 2016 at 17:28
258

Wow, I almost hate to add another answer when we have 57 different ways to recommend the NullObject pattern, but I think that some people interested in this question may like to know that there is a proposal on the table for Java 7 to add "null-safe handling"—a streamlined syntax for if-not-equal-null logic.

The example given by Alex Miller looks like this:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

The ?. means only de-reference the left identifier if it is not null, otherwise evaluate the remainder of the expression as null. Some people, like Java Posse member Dick Wall and the voters at Devoxx really love this proposal, but there is opposition too, on the grounds that it will actually encourage more use of null as a sentinel value.


Update: An official proposal for a null-safe operator in Java 7 has been submitted under Project Coin. The syntax is a little different than the example above, but it's the same notion.


Update: The null-safe operator proposal didn't make it into Project Coin. So, you won't be seeing this syntax in Java 7.

11
  • 23
    I think this is wrong. There should be a way to specify that a given variable is ALWAYS non-null. May 26, 2009 at 11:54
  • 6
    Update: the proposal will not make Java7. See blogs.sun.com/darcy/entry/project_coin_final_five . Aug 29, 2009 at 18:56
  • 11
    Interesting idea but the choice of syntax is absurd; I don't want a codebase full of question marks pinned into every joint.
    – Rob
    May 16, 2012 at 11:51
  • 8
    This operator exists in Groovy, so those who want to use it still have that as an option.
    – Muhd
    Feb 15, 2013 at 22:53
  • 11
    This is the most ingenious idea I've seen. It should be added to every sensible language of the C syntax. I'd rather "pin question marks" everywhere than scroll through screenful of lines or dodge "guard clauses" all day. Oct 1, 2015 at 20:57
214

If undefined values are not permitted:

You might configure your IDE to warn you about potential null dereferencing. E.g. in Eclipse, see Preferences > Java > Compiler > Errors/Warnings/Null analysis.

If undefined values are permitted:

If you want to define a new API where undefined values make sense, use the Option Pattern (may be familiar from functional languages). It has the following advantages:

  • It is stated explicitly in the API whether an input or output exists or not.
  • The compiler forces you to handle the "undefined" case.
  • Option is a monad, so there is no need for verbose null checking, just use map/foreach/getOrElse or a similar combinator to safely use the value (example).

Java 8 has a built-in Optional class (recommended); for earlier versions, there are library alternatives, for example Guava's Optional or FunctionalJava's Option. But like many functional-style patterns, using Option in Java (even 8) results in quite some boilerplate, which you can reduce using a less verbose JVM language, e.g. Scala or Xtend.

If you have to deal with an API which might return nulls, you can't do much in Java. Xtend and Groovy have the Elvis operator ?: and the null-safe dereference operator ?., but note that this returns null in case of a null reference, so it just "defers" the proper handling of null.

6
  • 24
    Indeed, the Option pattern is awesome. Some Java equivalents exist. Guava contains a limited version of this called Optional which leaves out most of the functional stuff. In Haskell, this pattern is called Maybe.
    – Ben Hardy
    May 20, 2011 at 18:31
  • @Luca Molteni: You're absolutely right, I already commented on the post to request expanding it. :)
    – thSoft
    Sep 11, 2011 at 20:59
  • 11
    An Optional class will be available in Java 8 Apr 25, 2013 at 14:59
  • 2
    ...and it doesn't (yet) have map nor flatMap: download.java.net/jdk8/docs/api/java/util/Optional.html
    – thSoft
    Apr 25, 2013 at 15:28
  • 4
    The Optional pattern doesn't solve anything; instead of one potentially null object, now you have two.
    – Boann
    Nov 4, 2013 at 4:15
212

Only for this situation -

Not checking if a variable is null before invoking an equals method (a string compare example below):

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) ) {
 // ...
}
5
  • 44
    I agree - only in that situation. I can't stand programmers that have taken this to the next unnecessary level and write if (null != myVar)... just looks ugly to me and serves no purpose! May 23, 2011 at 18:14
  • 21
    This is a particular example, probably the most used, of a general good practice: if you know it, always do <object that you know that is not null>.equals(<object that might be null>);. It works for other methods other than equals if you know the contract and those methods can handle null parameters.
    – Stef
    Sep 23, 2011 at 1:20
  • 9
    This is the first example I have seen of Yoda Conditions that actually makes sense Sep 30, 2013 at 19:37
  • 7
    NullPointerExceptions are thrown for a reason. They are thrown because an object is null where it shouldn't be. It is the programmers job to FIX this, not HIDE the problem. May 12, 2014 at 7:49
  • This only hides the problem. What if you are using foo later on? If a variable shouldn't be null, but is...your app needs to get a NPE so you as the developer can actually fix the underlying reason. Nov 26, 2015 at 8:57
189

Java 8 introduced the java.util.Optional class that addresses some of the problem. One can at least say that it improves the readability of the code, and in the case of public APIs make the contract clearer to the client developer.

They work as follows:

An optional object for a given type (Fruit) is created as the return type of a method. It can be empty or contain a Fruit object:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

Now look at this code where we search a list of Fruit (fruits) for a given Fruit instance:

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get(); // Prefer found.orElseThrow() in Java 9+
   String name = fruit.getName();
}

You can use the map method to perform a computation on — or extract a value from — an optional object. The orElse method lets you provide a fallback for missing values, converting an Optional to a non-nullable value.

String nameOrFallback = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

Of course, handling the null/empty value is still necessary, but at least the developer is conscious that the value might be empty and the risk of forgetting to check is limited.

In an API built from scratch using Optional whenever a return value might be empty, and returning a plain object only when it cannot be null (convention), the client code might abandon null checks on simple object return values.

Of course Optional could also be used as a method argument, perhaps a better way to indicate optional arguments than 5 or 10 overloading methods in some cases. Be aware that using it in this manner is recommended against by Java Language Architect Brian Goetz: "You should almost never use Optional as […] a method parameter."

Optional offers other convenient methods, such as orElseGet that calculates a default value only if the Optional is empty, and ifPresent that peforms an operation only if the Optional is non-empty, both of which work with lambda expressions.

I invite you to read this article (the main source for writing this answer) in which the problematic behavior of NullPointerException (and in general null pointer) and the (partial) solution brought by Optional are well explained: Java Optional Objects.

7
  • 12
    Google's guava has an optional implimention for Java 6+. May 27, 2013 at 17:30
  • 19
    It's very important to emphasise that using Optional only with ifPresent() does not add much value above normal null checking. It's core value is that it is a monad that can be used in function chains of map/flapMap, which achieves results similar to the Elvis operator in Groovy mentioned elsewhere. Even without this usage, though, I find the orElse/orElseThrow syntax also very useful. Oct 9, 2014 at 14:57
  • This blog has a good entry on Optional winterbe.com/posts/2015/03/15/avoid-null-checks-in-java
    – JohnC
    Dec 9, 2015 at 0:05
  • 6
    Why people have tendency to do this if(optional.isPresent()){ optional.get(); } instead of optional.ifPresent(o -> { ...}) Mar 7, 2018 at 15:06
  • 1
    So, other than the API contractual hints, it's really just about catering to functional programmers who enjoy chaining methods endlessly.
    – crush
    Aug 9, 2018 at 17:39
136

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.

Here follows an example of how you can use null vallidation in JAVA when you include apache library(commons-lang-2.4.jar)

public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
    Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
    return read(new StringReader(xml), true, validationEventHandler);
}

And if you are using Spring, Spring also has the same functionality in its package, see library(spring-2.4.6.jar)

Example on how to use this static classf from spring(org.springframework.util.Assert)

Assert.notNull(validationEventHandler,"ValidationHandler not Injected");
3
  • 5
    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"); commons.apache.org/lang/apidocs/org/apache/commons/lang/…
    – monojohnny
    Jan 14, 2010 at 13:57
  • @monojohnny does Validate use Assert statements into?. i ask that because Assert may be activate / deactivate on JVM and it's suggest do not use in production. Dec 9, 2017 at 16:03
  • Don't think so - I believe it just throws a RuntimeException if validation fails
    – monojohnny
    Jan 6, 2018 at 14:45
106
  • 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

1
97

I'm a fan of "fail fast" code. Ask yourself - are you doing something useful in the case where the parameter is null? If you don't have a clear answer for what your code should do in that case... i.e. - it should never be null in the first place, then ignore it and allow a NullPointerException to be thrown. The calling code will make just as much sense of an NPE as it would an IllegalArgumentException, but it'll be easier for the developer to debug and understand what went wrong if an NPE is thrown rather than your code attempting to execute some other unexpected contingency logic - which ultimately results in the application failing anyway.

1
  • 2
    better to use assertions, i.e Contract.notNull(abc, "abc must be non-null, did it fail to load during xyz?"); - this is a more compact way than doing an if (abc!=null) { throw new RuntimeException...}
    – ianpojman
    Oct 18, 2012 at 3:35
87

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. It is most useful for equals: Instead of foo.equals("bar"); better do "bar".equals(foo);.

2
  • 2
    But then you have to assume equals (could be any method) will handle null correctly. Really all this is doing is passing the responsibility to someone else (or another method).
    – Supericy
    Jun 13, 2013 at 20:01
  • 5
    @Supericy Basically yes, but equals (or whatever method) has to check for null anyway. Or state explicitly that it does not. Jul 30, 2013 at 7:26
84

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.

5
  • 19
    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. Oct 31, 2009 at 9:02
  • 1
    With Andersen - I would love Java's exception system to be able to include the name of a variable that's being worked upon, so that NullPointerExceptions would not only indicate the line the exception occurred on, but also the variable name. This should work just fine in unobfuscated software.
    – cthulhu
    Jan 18, 2011 at 12:53
  • 3
    I had a professor that preached against method call chaining. His theory was that you should be wary of call chains that were longer than 2 methods. I don't know if that's a hard rule, but it definitely removes most of the problems with NPE stack traces. Apr 16, 2013 at 17:12
  • @RustyTheBoyRobot You could just put each call on the chain on its own line. That way you can still chain until the cows come home, but you know exactly where things went awry. Feb 1, 2023 at 9:37
  • In java17 the error-message of a NullPointerException finally includes some important details in the message: dev.to/harsvnc/the-new-nullpointer-exception-in-java-17-4bcb
    – julaine
    Jan 22 at 15:56
83

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).doCalc();
7
  • 78
    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
    May 18, 2009 at 23:26
  • 17
    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) May 26, 2009 at 11:56
  • 7
    This is now part of Google Guava. Feb 13, 2011 at 20:55
  • 38
    Smells like over-engineering to me. Just let the JVM throw an NPE and don't clutter your code with this junk. Apr 23, 2012 at 19:11
  • 7
    I like it and open most methods and constructors with explicit checks on the arguments; if there is an error, methods always fail on the first few lines and I know the offending reference without finding something like getThing().getItsThing().getOtherThing().wowEncapsulationIsBroken().setLol("hi"); Nov 22, 2012 at 6:26
78

Null is not a 'problem'. It is an integral part of a complete modeling tool set. Software aims to model the complexity of the world and null bears its burden. Null indicates 'No data' or 'Unknown' in Java and the like. So it is appropriate to use nulls for these purposes. I don't prefer the 'Null object' pattern; I think it rise the 'who will guard the guardians' problem.
If you ask me what is the name of my girlfriend I'll tell you that I have no girlfriend. In the Java language I'll return null. An alternative would be to throw meaningful exception to indicate some problem that can't be (or don't want to be) solved right there and delegate it somewhere higher in the stack to retry or report data access error to the user.

  1. For an 'unknown question' give 'unknown answer'. (Be null-safe where this is correct from business point of view) Checking arguments for null once inside a method before usage relieves multiple callers from checking them before a call.

    public Photo getPhotoOfThePerson(Person person) {
        if (person == null)
            return null;
        // Grabbing some resources or intensive calculation
        // using person object anyhow.
    }
    

    Previous leads to normal logic flow to get no photo of a non-existent girlfriend from my photo library.

    getPhotoOfThePerson(me.getGirlfriend())
    

    And it fits with new coming Java API (looking forward)

    getPhotoByName(me.getGirlfriend()?.getName())
    

    While it is rather 'normal business flow' not to find photo stored into the DB for some person, I used to use pairs like below for some other cases

    public static MyEnum parseMyEnum(String value); // throws IllegalArgumentException
    public static MyEnum parseMyEnumOrNull(String value);
    

    And don't loathe to type <alt> + <shift> + <j> (generate javadoc in Eclipse) and write three additional words for you public API. This will be more than enough for all but those who don't read documentation.

    /**
     * @return photo or null
     */
    

    or

    /**
     * @return photo, never null
     */
    
  2. This is rather theoretical case and in most cases you should prefer java null safe API (in case it will be released in another 10 years), but NullPointerException is subclass of an Exception. Thus it is a form of Throwable that indicates conditions that a reasonable application might want to catch (javadoc)! To use the first most advantage of exceptions and separate error-handling code from 'regular' code (according to creators of Java) it is appropriate, as for me, to catch NullPointerException.

    public Photo getGirlfriendPhoto() {
        try {
            return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
        } catch (NullPointerException e) {
            return null;
        }
    }
    

    Questions could arise:

    Q. What if getPhotoDataSource() returns null?
    A. It is up to business logic. If I fail to find a photo album I'll show you no photos. What if appContext is not initialized? This method's business logic puts up with this. If the same logic should be more strict then throwing an exception it is part of the business logic and explicit check for null should be used (case 3). The new Java Null-safe API fits better here to specify selectively what implies and what does not imply to be initialized to be fail-fast in case of programmer errors.

    Q. Redundant code could be executed and unnecessary resources could be grabbed.
    A. It could take place if getPhotoByName() would try to open a database connection, create PreparedStatement and use the person name as an SQL parameter at last. The approach for an unknown question gives an unknown answer (case 1) works here. Before grabbing resources the method should check parameters and return 'unknown' result if needed.

    Q. This approach has a performance penalty due to the try closure opening.
    A. Software should be easy to understand and modify firstly. Only after this, one could think about performance, and only if needed! and where needed! (source), and many others).

    PS. This approach will be as reasonable to use as the separate error-handling code from "regular" code principle is reasonable to use in some place. Consider the next example:

    public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
        try {
            Result1 result1 = performSomeCalculation(predicate);
            Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
            Result3 result3 = performThirdCalculation(result2.getSomeProperty());
            Result4 result4 = performLastCalculation(result3.getSomeProperty());
            return result4.getSomeProperty();
        } catch (NullPointerException e) {
            return null;
        }
    }
    
    public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
        SomeValue result = null;
        if (predicate != null) {
            Result1 result1 = performSomeCalculation(predicate);
            if (result1 != null && result1.getSomeProperty() != null) {
                Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
                if (result2 != null && result2.getSomeProperty() != null) {
                    Result3 result3 = performThirdCalculation(result2.getSomeProperty());
                    if (result3 != null && result3.getSomeProperty() != null) {
                        Result4 result4 = performLastCalculation(result3.getSomeProperty());
                        if (result4 != null) {
                            result = result4.getSomeProperty();
                        }
                    }
                }
            }
        }
        return result;
    }
    

    PPS. For those fast to downvote (and not so fast to read documentation) I would like to say that I've never caught a null-pointer exception (NPE) in my life. But this possibility was intentionally designed by the Java creators because NPE is a subclass of Exception. We have a precedent in Java history when ThreadDeath is an Error not because it is actually an application error, but solely because it was not intended to be caught! How much NPE fits to be an Error than ThreadDeath! But it is not.

  3. Check for 'No data' only if business logic implies it.

    public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
        if (personId == null)
            return;
        DataSource dataSource = appContext.getStuffDataSource();
        Person person = dataSource.getPersonById(personId);
        if (person != null) {
            person.setPhoneNumber(phoneNumber);
            dataSource.updatePerson(person);
        } else {
            Person = new Person(personId);
            person.setPhoneNumber(phoneNumber);
            dataSource.insertPerson(person);
        }
    }
    

    and

    public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
        if (personId == null)
            return;
        DataSource dataSource = appContext.getStuffDataSource();
        Person person = dataSource.getPersonById(personId);
        if (person == null)
            throw new SomeReasonableUserException("What are you thinking about ???");
        person.setPhoneNumber(phoneNumber);
        dataSource.updatePerson(person);
    }
    

    If appContext or dataSource is not initialized unhandled runtime NullPointerException will kill current thread and will be processed by Thread.defaultUncaughtExceptionHandler (for you to define and use your favorite logger or other notification mechanizm). If not set, ThreadGroup#uncaughtException will print stacktrace to system err. One should monitor application error log and open Jira issue for each unhandled exception which in fact is application error. Programmer should fix bug somewhere in initialization stuff.

18
  • 7
    Catching NullPointerException and returning null is horrible to debug. You end up with NPE later on anyway, and it's really hard to figure out what was originally null.
    – artbristol
    Sep 14, 2013 at 8:44
  • 26
    I'd downvote if I had the reputation. Not only is null not necessary, it's a hole in the type system. Assigning a Tree to a List is a type error because trees are not values of type List; by that same logic, assigning null should be a type error because null is not a value of type Object, or any useful type for that matter. Even the man that invented null considers it his "billion-dollar mistake". The notion of "a value that might be a value of type T OR nothing" is its own type, and should be represented as such (e.g. Maybe<T> or Optional<T>).
    – Doval
    Nov 20, 2013 at 15:57
  • 3
    As of "Maybe<T> or Optional<T>" you still need to write code like if (maybeNull.hasValue()) {...} so what is the difference with if (maybeNull != null)) {...}?
    – Mike
    Apr 1, 2014 at 11:06
  • 2
    As of "catching NullPointerException and returning null is horrible to debug. You end up with NPE later on anyway, and it's really hard to figure out what was originally null". I'm totally agree! In those cases you should write a dozen of 'if' statements or throw NPE if business logic imply data in-place, or use null-safe operator from new Java. But there are cases when I don't care about what exact step give me null. For example calculating some values for the user just before showing on the screen when you do expect data could be missing.
    – Mike
    Apr 1, 2014 at 11:32
  • 4
    @MykhayloAdamovych: The benefit of Maybe<T> or Optional<T> isn't in the case where your T might be null, but in the case where it should never be null. If you have a type that explicitly means "this value might be null -- use with caution", and you use and return such a type consistently, then whenever you see a plain old T in your code, you can assume it is never null. (Course, this would be a lot more useful if enforceable by the compiler.)
    – cHao
    Nov 7, 2014 at 19:55
73

Java 7 has a new java.util.Objects utility class on which there is a requireNonNull() method. All this does is throw a NullPointerException if its argument is null, but it cleans up the code a bit. Example:

Objects.requireNonNull(someObject);
someObject.doCalc();

The method is most useful for checking just before an assignment in a constructor, where each use of it can save three lines of code:

Parent(Child child) {
   if (child == null) {
      throw new NullPointerException("child");
   }
   this.child = child;
}

becomes

Parent(Child child) {
   this.child = Objects.requireNonNull(child, "child");
}
7
  • 9
    Actually, your example constitutes code bloat: the first line is superfluous because the NPE would be thrown in the second line. ;-) Mar 7, 2013 at 1:21
  • 1
    True. A better example would be if the second line were doCalc(someObject). Mar 7, 2013 at 5:23
  • Depends. If you are the author of doCalc(), I'd suggest putting the check into that method's body (if possible). And then you most likely will call someObject.someMethod() where again there is no need to check for null. :-) Mar 7, 2013 at 7:07
  • Well, if you are not the author of doCalc(), and it doesn't immediately throw NPE when given null, you'd need to check for null and throw NPE yourself. That's what Objects.requireNonNull() is for. Mar 9, 2013 at 6:43
  • 7
    It's not just code bloat. Better to check up front than halfway through a method that causes side effects or uses time/space.
    – Rob Grant
    Sep 26, 2013 at 11:33
53

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 it can make errors much harder to diagnose.
  • In Nice, a Java-derived 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.
1
  • 5
    I am not familiar with Nice, but Kotlin implements the same idea, have nullable and not-null types build into the language's type system. A lot more concise than Optionals or null Object pattern.
    – mtsahakis
    Sep 17, 2018 at 19:29
40

Common "problem" in Java indeed.

First, my thoughts on this:

I consider that it is bad to "eat" something when NULL was passed where NULL isn't a valid value. If you're not exiting the method with some sort of error then it means nothing went wrong in your method which is not true. Then you probably return null in this case, and in the receiving method you again check for null, and it never ends, and you end up with "if != null", etc..

So, IMHO, null must be a critical error that prevents further execution (that is, where null is not a valid value).

The way I solve this problem is this:

First, I follow this convention:

  1. All public methods / API always check their arguments for null
  2. All private methods do not check for null since they are controlled methods (just let die with nullpointer exception in case it wasn't handled above)
  3. The only other methods which do not check for null are utility methods. They are public, but if you call them for some reason, you know what parameters you pass. This is like trying to boil water in the kettle without providing water...

And finally, in the code, the first line of the public method goes like this:

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

Note that addParam() returns self, so that you can add more parameters to check.

Method validate() will throw checked ValidationException if any of the parameters is null (checked or unchecked is more a design/taste issue, but my ValidationException is checked).

void validate() throws ValidationException;

The message will contain the following text if, for example, "plans" is null:

"Illegal argument value null is encountered for parameter [plans]"

As you can see, the second value in the addParam() method (string) is needed for the user message, because you cannot easily detect passed-in variable name, even with reflection (not the subject of this post anyway...).

And yes, we know that beyond this line we will no longer encounter a null value so we just safely invoke methods on those objects.

This way, the code is clean, easily maintainable, and readable.

1
  • 3
    Absolutely. Applications that just throw the error and crash are of higher quality because there is no doubt when they are not working. Applications that swallow the errors at best degrade gracefully but usually don't work in ways that are difficult to notice and don't get fixed. And when the problem is noticed they are much harder to debug. Nov 14, 2011 at 5:06
39

Asking that question points out that you may be interested in error handling strategies. How and where to handle errors is a pervasive architectural question. There are several ways to do this.

My favorite: allow the Exceptions to ripple through - catch them at the 'main loop' or in some other function with the appropriate responsibilities. Checking for error conditions and handling them appropriately can be seen as a specialized responsibility.

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

0
38

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) {
    .....
    .....



    .....
}
4
  • 2
    Mh, why that? Please don't feel any defensive, I'd just like to learn more about Java :) Aug 17, 2010 at 5:54
  • 9
    @Mudu As a general rule, I prefer the expression in an if statement to be a more "positive" statement, rather than a "negative" one. So if I saw if (!something) { x(); } else { y(); } I would be inclined to refactor it as if (something) { y(); } else { x(); } (though one could argue that != null is the more positive option...). But more importantly, the important part of the code is not wrapped inside {}s and you have one level less of indentation for most of the method. I don't know if that was fastcodejava's reasoning but that would be mine.
    – Tyler
    Jun 22, 2011 at 0:05
  • 2
    This is what I tend to do as well.. Keeps the code clean in my opinon. Dec 15, 2015 at 21:44
  • @MatrixFrog Yeah that makes the code cleaner and easily readable, as you see the important code (when everything function without errors) first.
    – Skaldebane
    Jun 22, 2020 at 22:41
37

Just don't ever use null. Don't allow it.

In my classes, most fields and local variables have non-null default values, and I add contract statements (always-on asserts) everywhere in the code to make sure this is being enforced (since it's more succinct, and more expressive than letting it come up as an NPE and then having to resolve the line number, etc.).

Once I adopted this practice, I noticed that the problems seemed to fix themselves. You'd catch things much earlier in the development process just by accident and realize you had a weak spot.. and more importantly.. it helps encapsulate different modules' concerns, different modules can 'trust' each other, and no more littering the code with if = null else constructs!

This is defensive programming and results in much cleaner code in the long run. Always sanitize the data, e.g. here by enforcing rigid standards, and the problems go away.

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

The contracts are like mini-unit tests which are always running, even in production, and when things fail, you know why, rather than a random NPE you have to somehow figure out.

5
  • why would this be downvoted? in my experience, this is far superior to the other approaches, would love to know why not
    – ianpojman
    Oct 31, 2012 at 21:31
  • I agree, this approach prevents problems related to nulls, rather than fixing them by speckling code null checks everywhere.
    – ChrisBlom
    Jul 27, 2013 at 10:48
  • 9
    The problem with this approach is that if name is never set, it has the value "<unknown>", which behaves like a set value. Now let's say I need to check if name was never set (unknown), I have to do a string comparison against the special value "<unknown>".
    – Steve Kuo
    Dec 17, 2013 at 7:02
  • 1
    True good point Steve. What I often do is have that value as a constant, e.g. public static final String UNSET="__unset" ... private String field = UNSET ... then private boolean isSet() { return UNSET.equals(field); }
    – ianpojman
    Jan 26, 2015 at 19:45
  • IMHO, This is a implementation of Null Object Pattern with a yourself implementation of Optional (Contract). How it behaves on persistence class class? I do not see applicable in that case. Dec 9, 2017 at 19:56
32

Guava, a very useful core library by Google, has a nice and useful API to avoid nulls. I find UsingAndAvoidingNullExplained very helpful.

As explained in the wiki:

Optional<T> is a way of replacing a nullable T reference with a non-null value. An Optional may either contain a non-null T reference (in which case we say the reference is "present"), or it may contain nothing (in which case we say the reference is "absent"). It is never said to "contain null."

Usage:

Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5
1
  • get() is never a good idea to use. You can use: val = funcThatReturnsOptional().orElse(CUSTOM_ERROR_DIFFERENT_USECASES); in one line and check the value for different usecases. May 25, 2023 at 8:32
28

This is a very common problem for every Java developer. So there is official support in Java 8 to address these issues without cluttered code.

Java 8 has introduced java.util.Optional<T>. It is a container that may or may not hold a non-null value. Java 8 has given a safer way to handle an object whose value may be null in some of the cases. It is inspired from the ideas of Haskell and Scala.

In a nutshell, the Optional class includes methods to explicitly deal with the cases where a value is present or absent. However, the advantage compared to null references is that the Optional<T> class forces you to think about the case when the value is not present. As a consequence, you can prevent unintended null pointer exceptions.

In above example we have a home service factory that returns a handle to multiple appliances available in the home. But these services may or may not be available/functional; it means it may result in a NullPointerException. Instead of adding a null if condition before using any service, let's wrap it in to Optional<Service>.

WRAPPING TO OPTION<T>

Let's consider a method to get a reference of a service from a factory. Instead of returning the service reference, wrap it with Optional. It lets the API user know that the returned service may or may not available/functional, use defensively

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

As you see Optional.ofNullable() provides an easy way to get the reference wrapped. There are another ways to get the reference of Optional, either Optional.empty() & Optional.of(). One for returning an empty object instead of retuning null and the other to wrap a non-nullable object, respectively.

SO HOW EXACTLY IT HELPS TO AVOID A NULL CHECK?

Once you have wrapped a reference object, Optional provides many useful methods to invoke methods on a wrapped reference without NPE.

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

Optional.ifPresent invokes the given Consumer with a reference if it is a non-null value. Otherwise, it does nothing.

@FunctionalInterface
public interface Consumer<T>

Represents an operation that accepts a single input argument and returns no result. Unlike most other functional interfaces, Consumer is expected to operate via side-effects. It is so clean and easy to understand. In the above code example, HomeService.switchOn(Service) gets invoked if the Optional holding reference is non-null.

We use the ternary operator very often for checking null condition and return an alternative value or default value. Optional provides another way to handle the same condition without checking null. Optional.orElse(defaultObj) returns defaultObj if the Optional has a null value. Let's use this in our sample code:

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

Now HomeServices.get() does same thing, but in a better way. It checks whether the service is already initialized of not. If it is then return the same or create a new New service. Optional<T>.orElse(T) helps to return a default value.

Finally, here is our NPE as well as null check-free code:

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if(homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

The complete post is NPE as well as Null check-free code … Really?.

1
  • There's a null check in above code - if(homeServices != null) { which can be changed to homeServices.ifPresent(h -> //action); Jan 2, 2020 at 12:36
25

I like articles from Nat Pryce. Here are the links:

In the articles there is also a link to a Git repository for a Java Maybe Type which I find interesting, but I don't think it alone could decrease the checking code bloat. After doing some research on the Internet, I think != null code bloat could be decreased mainly by careful design.

2
  • Michael Feathers has written an short and interesthing text about approaches like the one you mentioned: manuelp.newsblur.com/site/424 Jul 12, 2013 at 20:59
  • If there's anything I appreciated most about this answer, it's the "careful design" tip. Whether it boils down to writing code, fixing bugs or checking for nullity, it's DAMN CRUCIAL to make an overall good design and organisation in code, to avoid many redundancies that we still have to deal with today because of bad design choices made a long time ago...
    – Skaldebane
    Jun 24, 2020 at 21:49
23

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!

22

Probably the best alternative for Java 8 or newer is to use the Optional class.

Optional stringToUse = Optional.of("optional is there");
stringToUse.ifPresent(System.out::println);

This is especially handy for long chains of possible null values. Example:

Optional<Integer> i = Optional.ofNullable(wsObject.getFoo())
    .map(f -> f.getBar())
    .map(b -> b.getBaz())
    .map(b -> b.getInt());

Example on how to throw exception on null:

Optional optionalCarNull = Optional.ofNullable(someNull);
optionalCarNull.orElseThrow(IllegalStateException::new);

Java 7 introduced the Objects.requireNonNull method which can be handy when something should be checked for non-nullness. Example:

String lowerVal = Objects.requireNonNull(someVar, "input cannot be null or empty").toLowerCase();
0
18

May I answer it more generally!

We usually face this issue when the methods get the parameters in the way we not expected (bad method call is programmer's fault). For example: you expect to get an object, instead you get a null. You expect to get an String with at least one character, instead you get an empty String ...

So there is no difference between:

if(object == null){
   //you called my method badly!

}

or

if(str.length() == 0){
   //you called my method badly again!
}

They both want to make sure that we received valid parameters, before we do any other functions.

As mentioned in some other answers, to avoid above problems you can follow the Design by contract pattern. Please see http://en.wikipedia.org/wiki/Design_by_contract.

To implement this pattern in java, you can use core java annotations like javax.annotation.NotNull or use more sophisticated libraries like Hibernate Validator.

Just a sample:

getCustomerAccounts(@NotEmpty String customerId,@Size(min = 1) String accountType)

Now you can safely develop the core function of your method without needing to check input parameters, they guard your methods from unexpected parameters.

You can go a step further and make sure that only valid pojos could be created in your application. (sample from hibernate validator site)

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}
1
  • javax is, by definition, not "core Java".
    – Tomas
    Oct 30, 2015 at 4:02
17

I highly disregard answers that suggest using the null objects in every situation. This pattern may break the contract and bury problems deeper and deeper instead of solving them, not mentioning that used inappropriately will create another pile of boilerplate code that will require future maintenance.

In reality if something returned from a method can be null and the calling code has to make decision upon that, there should an earlier call that ensures the state.

Also keep in mind, that null object pattern will be memory hungry if used without care. For this - the instance of a NullObject should be shared between owners, and not be an unigue instance for each of these.

Also I would not recommend using this pattern where the type is meant to be a primitive type representation - like mathematical entities, that are not scalars: vectors, matrices, complex numbers and POD(Plain Old Data) objects, which are meant to hold state in form of Java built-in types. In the latter case you would end up calling getter methods with arbitrary results. For example what should a NullPerson.getName() method return?

It's worth considering such cases in order to avoid absurd results.

4
  • The solution with "hasBackground()" has one drawback - it's not thread-safe. If you need to call two methods instead of one, you need to synchronize the whole sequence in multi-threaded environment.
    – pkalinow
    Feb 3, 2016 at 12:26
  • @pkalinow You made a contrived example only to point out that this solution has a drawback. If code is not meant to run in multithreaded application then there is no drawback. I could put at you probably 90% of your code that is not thread safe. We're not speaking here about this aspect of code, we're speaking about design pattern. And multithreading is a topic on its own.
    – luke1985
    Feb 3, 2016 at 15:29
  • Of course in a single-thread application it's not a problem. I've given that comment because sometimes it is a problem.
    – pkalinow
    Feb 4, 2016 at 10:34
  • @pkalinow If you study this topic closer you will find out that Null Object design pattern won't fix the multithreading problems. So it's irrelevant. And to be honest, I've found places where this pattern would fit in nicely, so my original answer is a bit wrong, actually.
    – luke1985
    Feb 4, 2016 at 10:57
16
  1. Never initialise variables to null.
  2. If (1) is not possible, initialise all collections and arrays to empty collections/arrays.

Doing this in your own code and you can avoid != null checks.

Most of the time null checks seem to guard loops over collections or arrays, so just initialise them empty, you won't need any null checks.

// Bad
ArrayList<String> lemmings;
String[] names;

void checkLemmings() {
    if (lemmings != null) for(lemming: lemmings) {
        // do something
    }
}



// Good
ArrayList<String> lemmings = new ArrayList<String>();
String[] names = {};

void checkLemmings() {
    for(lemming: lemmings) {
        // do something
    }
}

There is a tiny overhead in this, but it's worth it for cleaner code and less NullPointerExceptions.

2
  • 3
    +1 This I agree with. You should never return half initialized objects. Jaxb related code and bean code is notiroius for this. It is bad practice. All collections should be initialized, and all objects should exist with (ideally) no null references. Consider a object that has a collection in it. Checking that the object is not null, that the collection is not null and that the collection does not contain null objects is unreasonable and foolish.
    – ggb667
    Sep 23, 2013 at 14:52
15

This is the most common error occurred for most of the developers.

We have number of ways to handle this.

Approach 1:

org.apache.commons.lang.Validate //using apache framework

notNull(Object object, String message)

Approach 2:

if(someObject!=null){ // simply checking against null
}

Approach 3:

@isNull @Nullable  // using annotation based validation

Approach 4:

// by writing static method and calling it across whereever we needed to check the validation

static <T> T isNull(someObject e){  
   if(e == null){
      throw new NullPointerException();
   }
   return e;
}
2
  • Ad. 4. It is not very useful - when you check if a pointer is null, you probably want to call a method on it. Calling a method on null gives you the same behavior - NullPointerException.
    – pkalinow
    Feb 3, 2016 at 12:18
  • Approach 4 is superfluous and already covered by Objects.requireNonNull()
    – fozzybear
    Mar 22, 2023 at 16:25
13

Java 8 has introduced a new class Optional in java.util package.

Advantages of Java 8 Optional:

1.) Null checks are not required.
2.) No more NullPointerException at run-time.
3.) We can develop clean and neat APIs.

Optional - A container object which may or may not contain a non-null value. If a value is present, isPresent() will return true and get() will return the value.

For more details find here oracle docs :- https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html

1
  • It should be noted, that Optionals are supposed to be used primarily for return values, as empty Objects to work without consecutive NPE problems, not as a replacement for null checks e. g. in legacy or conventional code.
    – fozzybear
    Mar 22, 2023 at 16:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.