Null pointers/nullable
See original GitHub issueI can see that most of the issues marked as “bugs” in SonarCloud are Null pointers should not be dereferenced
which risks throwing a NullReferenceException
As an example I looked into this issue: https://sonarcloud.io/project/issues?issues=AYRH0TRT_qq9ReJdi4pi&open=AYRH0TRT_qq9ReJdi4pi&id=apache_lucenenet
Here I tracked the newest version of the code down here: https://github.com/apache/lucene/blob/7c130d2f07e00fd8725cf7e22cc268dd4331fbbe/lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/ConvTable.java#L59
Which is similar to the version we have which should therefore mean that the same issue is still present in the Java version too? Therefore I’m wondering what’s the best approach for fixing these errors or if they should be fixed at all. It’s very possible that it’s next to impossible to encounter this error in a real world scenario. (I haven’t looked too much into how it’s used).
And related to this, would it make sense to enable the Nullable feature across the project to give a informative public API for the developers using Lucene.NET? Here we could mark variables and parameters that can be null at some point. This should be possible to do step by step by adding the #nullable enable
that I can see you’ve used in some files.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
Well, that is because you know what you are doin’ 😃.
But those mere mortals who allow a
null
to pass into one of our APIs might be chasing their tail for awhile because the null gets passed down through 5 or so more APIs before it hits the one that throws. A guard clause makes the stack trace much more explicit as to where the problem lies. And who knows how long they will chase their tail if they don’t even have a vague notion that they can turn on asserts.I don’t think you guys appreciate the power that the scan gave us. It turned ~1500 hours of unspecified work with a vague notion of “let’s fix the main APIs first” into a very targeted few dozen hours of work to hit the most problematic areas first. All while avoiding having to change exception behavior in a breaking way after the release.
Sure, this was near the bottom in terms of priority - and still is - but having a hard target to hit bumps it up a bit in my opinion. Clean up the squeaky wheels that the scan gave us, and then fix the rest at some point after the release (most notably, the APIs that allow null that the scan isn’t showing us).