[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 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
NullPointerExceptionwhile running theTryFailRefactoringcheck.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I'm seeing the
NullPointerExceptionbelow via theTryFailRefactoringcheck 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: