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.
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.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With