NPEs being reported - is this a false positive?

Must-share information (formatted with Markdown):

  • SonarQube Enterprise Edition Version 9.9.2 (build 77730)
  • No idea how it has been deployed
  • I want to understand if my issue is a false positive reporting of a potential NPE
  • Looked at the analysis and tried to follow the code

(Sorry this is the first time I’ve used this community and am probably doing this terribly wrong)


I am working on a large-scale project and our Application Security team have asked me to look at some issues regarding NPEs being reported by SonarQube.

The issue is reported as:

A “NullPointerException” could be thrown; “responseMessage” is nullable here.

I can’t paste all of the code here, but the simplified form is:

private void myMethod() {
    String responseMessage = obtainResponseMessage();  // This method may return null
    if(responseMessage != null) {
        LOG.error("The responseMessage is " + responseMessage);
   // Do more work here - removed since not relevant
   if (HelperUtil.validString(responseMessage)) {
      if (responseMessage.equals("User account locked")) {
          // Report that the user account is locked

SonarQube complains the responseMessage could be null at the last ‘if statement’. From the above it is clear that it coule be null. However the key aspect is on the line prior to the last ‘if statement’. The call to the static method “validString” in class: HelperUtil . The code is the following:

public static boolean validString(String...strings) {
    if(strings == null) {
        return false;
    for(String s : strings) {
        if(s == null || s.length() == 0) { return false; }
        if(s.trim().length() == 0) {  return false;  }
    return true;

So how could the last if statement ever be reached if ‘responseMessage’ is null? Am I missing something or is this a deficiency in SonarQube I trust SonarQube but I just can’t see how this can be null.



Welcome to the community!

Unfortunately this rule implementation isn’t sophisticated enough to follow the control flow through your helper method, which is why a False Positive is raised here.

Your best bet is just to mark it FP in the UI.


Thanks. Do you think it is the fact that the method “validString” takes a VarArgs rather than a String? I believe I’ve seen SonarQube cope with following logic when the parameter is just a String. I would set up an example to test, but like I say, I am working on a large-scale project and don’t just want to submit code to the codebase in order to test SonarQube


No, it’s just that this rule isn’t following the control flow out of… the method(?). To be honest, this is a rule we implemented several years ago, now. Our detection has gotten much more sophisticated since then, but this implementation hasn’t been revisited.