-
Notifications
You must be signed in to change notification settings - Fork 737
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
[2.3.4] NPE in TryFailRefactoring #1447
Comments
Seems possibly similar to #1155 . I'll see if I can create a standalone reproducer. |
Here's a class that reproduces the NPE for me. package example;
class TryFailRefactoringNpe {
static {
try {
Integer.parseInt("hello");
} catch (NumberFormatException e) {
e.printStackTrace();
}
}
} That causes a problem for the first line of code in error-prone/core/src/main/java/com/google/errorprone/bugpatterns/TryFailRefactoring.java Lines 62 to 64 in 1bedd95
because Adding a MethodTree methodTree = state.findEnclosing(MethodTree.class);
if (methodTree == null || !JUnitMatchers.TEST_CASE.matches(methodTree, state)) {
return NO_MATCH;
} To understand why MethodTree methodTree = state.findEnclosing(MethodTree.class);
if (methodTree == null) {
System.out.println("NULL METHOD TREE!");
TreePath path = state.getPath();
while (path != null) {
Tree leaf = path.getLeaf();
System.out.println();
System.out.println("----------------------------");
System.out.println(leaf.getClass().getName());
System.out.println("----------------------------");
System.out.println(leaf);
path = path.getParentPath();
}
} It thinks the enclosing tree elements are:
No |
Thanks for the report. I've sent a fix internally that should be out in a future release. |
Fixes external #1447 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=287975763
Fixes external #1447 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=287975763
Most issues fixed were the UnnecessaryLambda[1], those, mostly constant fields were converted to, mostly, static methods. There was a need to convert some of the static initialization blocks to methods as an issue in errorprone was triggered[2]. Refactoring those static blocks to static methods in my opinion makes them more readable and it allows, if one would have impetus to do so, to write tests against them. [1] https://errorprone.info/bugpattern/UnnecessaryLambda [2] google/error-prone#1447
Fixes external google#1447 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=287975763
Most issues fixed were the UnnecessaryLambda[1], those, mostly constant fields were converted to, mostly, static methods. There was a need to convert some of the static initialization blocks to methods as an issue in errorprone was triggered[2]. Refactoring those static blocks to static methods in my opinion makes them more readable and it allows, if one would have impetus to do so, to write tests against them. [1] https://errorprone.info/bugpattern/UnnecessaryLambda [2] google/error-prone#1447
Thanks! |
Description of the problem:
After upgrading to error-prone 2.3.4, I'm encountering a few issues that may be error-prone bugs according to their failure stacktraces. In this specific case there is a
NullPointerException
while running theTryFailRefactoring
check.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I'm seeing the
NullPointerException
below via theTryFailRefactoring
check during compilation. Example PR palantir/tritium#537 with build output at https://circleci.com/gh/palantir/tritium/5745 showing the following stacktrace. This appears to point at https://github.com/palantir/tritium/blob/ds/error-prone-javadoc/tritium-tracing/src/main/java/com/palantir/tritium/tracing/RemotingCompatibleTracingInvocationEventHandler.java#L48 with the following try/catch:What version of Error Prone are you using?
2.3.4
The text was updated successfully, but these errors were encountered: