sonarLint complains “Null pointers should not be dereferenced (squid:S2259)” despite that possibility being handled

Question

So I have an issue with SonarLint that I am not sure how to approach.

let's say I have a class with a method

public class Class(RemoteContext context)
    RemoteContext context = context;

    public void String method(String data) {
        if(data == null)
            context.raiseException("data can't be null");

        //do stuff with data like data.get();
    }

When I analyze this class with sonarLint (3.2.) I get a Null pointer should not be dereferenced issue.

So my question is. How to solve this issue? context.RaiseException will stop method execution so I think it is a false positive.

The application has a lot of cases (classes/methods) with this problem. So I'm thinking that annotations are an overkill (ugly code all around) I could also type return after each raiseException() call, but I'm under the impression that is not the "programmers way".

I'm guessing writing my own rule would be best.

I was looking over the topics and did me googling around but did not find anything useful for this case, when I sort of having to do the "opposite" of what sonar actually does. Not raising an issue, but kind of "giving a green light" on the method?

Hopefully, I was clear enough on the issue.

Answer 1

If RemoteContext is a class you control, and you really don't want to use the usual new ExceptionType(...) pattern, I would change RemoteContext to build the exception but not throw it, and then

if (data == null) {
    throw context.buildException("data can't be null");
}

...so that it's clear to SonarLint, to the Java compiler, and to programmers doing work on the code later that execution of the method stops at that point (since "raise exception" can mean a lot of things).

(Yes, this means changing the lots of places you have this, but a relatively simply search-and-replace achieves that.)

Answer 2

There aren't really elegant ways to solve this. What does work:

 public SomeException createAndThrow() {
   throw new SomeException();
 }

To be used like:

 throw createAndThrow();

That gives you like "double locking":

• your utility method throws ... but in case it would not throw
• you assume that an exception object is simply returned, so lets throw that one

Other languages, such as C++ even allow to express: this method/function is not support to return normally. But Java doesn't offer that.