New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MagicNumberCheck NPE when ignoring field declarations #14788
Comments
It should also be looked into why regression did not find this, and what we can do to ensure we try to find this in the future. |
@rnveach I'm not sure if checkstyle uses either fuzzing or mutation testing in its build. Those techniques might find such or similar errors, but honestly I also don't have much practical experience with them (only used them in very small exploration projects). |
We use pitest which is mutation testing, however, if anything it requires us to either to regress changes to find test cases or to remove code completely and wait for users to report issues. While it has its benefits, some of the maintainers don't see it as a good thing since we majority of the time just remove code it complains about. Some contributors can't do a deep dive on creating test cases because our tree is so complex and some checks are even more complex to understand what is needed. |
I am on this |
Do we have any signal from checker framework on this possibility of npe? |
@Bananeweizen If you look at e39e63e#diff-acd097abaf44b6edc9c81324f8c969963b793cbbc39487a470c6ead350f0dc67L528 which introduced this issue, you can see this code use to have a |
@romani, I didn't see any signal from checker-framework when fixing this bug. There is no corresponding checker suppressions either. |
I meant, maybe there is suppression already about this Check and around this code |
@rnveach that kind of error would be almost impossible at my work. Most fields, return values and arguments are null annotated. The eclipse compiler would not compile the access with the missing null check then. Let me show you: When I then try to "fix" that by declaring that variable as nonnull to make the dereference operation okay, the compiler rightfully complains about the return of getParent() (which I annoated as Nullable now. If I left away that annotation for the getParent(), the compiler would not recognize this error. This would be the most work for using that mechanism large scale, really annotating all the stuff that can be null). So obviously the variable must be declared nullable instead, and then the compiler points right at this bug (again): Annotating the getParent() method now causes 91 compiler errors in Eclipse for potential null pointer access. I maintain a 7 digit Java code base at work, and null pointers in our own code happen like twice a year only. This demo was done using the Eclipse compiler and it's own null annotation library (org.eclipse.jdt.annotations). Using the checker framework library instead should work for 90% of the cases, however, the actual analysis is in the compiler, not in the library. Therefore I'm not sure how well that fits to your typical build and development tooling usage. I'm not sure if the checker framework alone can be used similarly. |
Is this number of files or lines?
Until you add in pitest and have a requirement of no suppressions with pitest. These last 2 lead us to have only code we can prove we need. See #14788 (comment)
@nrmancuso @romani This method (
I have seen this before. There have been times I enabled it and don't see how a The mentality of this project is that if we can't prove the code is needed, we wait for the users to report it. So getting NPE like this (or other issues) would just be the natural outcome. |
One day in future we will focus on checker framework, to get more benefits. |
Reported at checkstyle/sonar-checkstyle#519
Expecting no exception.
Module code analysis at checkstyle/sonar-checkstyle#519 (comment)
The text was updated successfully, but these errors were encountered: