Thanks for the feedback regarding rule S2259.
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.
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.