Version: Community Edition Version 7.9.1 (build 27448)
error observed:
The following scenario should raise an issue (Null pointers should not be dereferenced (squid:S2259)) in method getB() on calling getB() on potential null getA() return value.
public A getA() {
if (isCheck()) {
return null;
}
return nonNull;
}
public B getB() {
return getA().getB(); // should raise issue
}
steps to reproduce: see code above
potential workaround: Make method final (if possible)
In my opinion that scenario should raise an issue.
Unfortunately, you are hitting here one of the limitations of the SonarJava Symbolic Execution (SE) engine, used by this rule. One of the very challenging aspect of the engine is about how to handle overrides, which is perfectly illustrated by your example.
Because method getA() can potentially be overridden by another implementation (subclass of A), the engine can not be sure that getA() will behave all the time as implemented in the current class under analysis. In order to avoid noise and raising FPs, we therefore took the decision to stay silent here.
Note that there is some other workarounds:
Clarify the method’s contract:
by annotatint the method with @javax.annotation.CheckForNull (from JSR-305)
Make the method non-overridable, by:
making the method private
making the method static
making the parent class final
Another approach could be for us to check all the possible implementations of getA() existing in the context of the project, but this is something we don’t plan to work on at the moment. The relevance of the results would also be quite challenging.