Possible null pointer exception in string utils

Question

I am using commons StringUtils.isNotBlank() to check if a string is not empty and blank. In some scenarios for a blank string or a null as input validation is not happening as expected. Null or blank is getting through.

   if( StringUtils.isNotEmpty(obj.getvalue()) ){
        .............
    }

When I go through the documentation of StringUtils I found,

A side effect of the null handling is that a NullPointerException should be considered a bug in StringUtils (except for deprecated methods).

What dose it mean? It has got anything to do with my scenario?

Answer 1

In some scenarios for a blank string or a null as input validation is not happening as expected. Null or blank is getting through.

Either there is a bug in your validation logic, or you have data coming from a source that has not been subjected to validation.

If you posted the actual code and the NPE stacktrace, we could help you find it.

---

What does it mean?

It means that if StringUtils.isNotBlank() throws an NPE, then there is a bug in the method. (The "side effect" that the javadoc is talking about is a logical side-effect; i.e. a secondary logical consequence of the way that the API is defined.)

It has got anything to do with my scenario?

It has nothing to do with it ... unless a call to StringUtils.isNotBlank()is throwing an NPE.

---

UPDATE

Considering your example code (tweaked for illustrative purposes):

if (StringUtils.isNotEmpty(obj.getvalue())){
    String s = obj.getvalue();
    if (s == null) {
        System.err.println("Ooops!!");
    }
}

I can think of a number of scenarios in which this code could either give an NPE or cause "Ooops!" to be printed. For instance:

1. If obj is null then an NPE will definitely be thrown. This could happen before you called isNotEmpty, or (if the value of the obj variable can be changed can be changed) in the "then" block.

2. It is possible that the getValue method could throw an NPE.

3. It is possible (but unlikely) that calling getValue has a side-effect that causes it to change the state of obj and return a different value (e.g. null) on the 2nd call. Ooops!

4. It is possible that some other thread is changing the state of the obj object while the current thread is executing the above code. Ooops!

Most of these problems could be "fixed" as follows:

String s = obj.getvalue();
if (StringUtils.isNotEmpty(s)){ // No NPE possible here now
    if (s == null) {
        System.err.println("Ooops!!");  // Cannot happen now.
    }
}

Answer 2

Read the sentence above the one you quoted:

StringUtils handles null input Strings quietly. That is to say that a null input will return null. Where a boolean or int is being returned details vary by method.

A side effect of the null handling is that a NullPointerException should be considered a bug in StringUtils (except for deprecated methods).

So since it handles null values it shouldn't throw NullPointerExceptions.

And if you check out the method, isNotBlank, you'll find this table:

 StringUtils.isNotBlank(null)      = false
 StringUtils.isNotBlank("")        = false
 StringUtils.isNotBlank(" ")       = false
 StringUtils.isNotBlank("bob")     = true
 StringUtils.isNotBlank("  bob  ") = true

if you are receiving other values you are indeed experiencing a bug, which you should report. But it is more likely that the NPE is caused by something else. Maybe some other StringUtils method returned null, for example.

Answer 3

For an in detail examination of your problem, you could post a specific example where the code goes wrong in your opinion.

StringUtils Behaviour

• StringUtils.isNotBlank(null) returns false
• StringUtils.isNotBlank("") returns false
• StringUtils.isNotBlank(" ") returns false
• StringUtils.isNotBlank(" testvalue") returns true

If the behaviour is anything else, this is a bug in the libary

Answer 4

Is it possible that NPE is thrown from obj.getvalue() as StringUtils.isNotBlank() will never throw a NPE. If you are running your code in a multi-threaded environment you can make your method synchronized so it prevents simultaneous access to your method from multiple sources.

For more help can you send your stack trace or code block?

Answer 5

There is actually a bug either in the StringUtils.isNotBlank() method or in the documentation. If you pass a null to isNotBlank() it will toss a NullPointerException which is contrary to the documentation. Thus one or the other (code or documentation) is incorrect.

Here's a good replacement using Guave from: http://www.javaworld.com/article/2074361/core-java/checking-for-null-or-empty-or-white-space-only-string-in-java.html