Description
Infer incorrectly reports a "Dangling Pointer Dereference" error for the exception parameter e in a catch block of a try-with-resources statement, claiming it is an "uninitialized object" that could be dangling when dereferenced. This is a false positive, as Java's exception handling semantics ensure the parameter is always initialized by the JVM when the catch block executes.
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
class a {
void method() {
try (BufferedReader br = new BufferedReader(new FileReader("file.txt"))) {
br.readLine();
} catch (IOException e) { // <-should not report(FP)
e.printStackTrace();
}
}
}
Expected behavior:
No DANGLING_POINTER_DEREFERENCE should be reported because:
The catch parameter e is implicitly initialized by the JVM (per JLS §14.20) when an IOException is thrown from the try block (e.g., from FileReader constructor, readLine(), or implicit close()).
If no exception occurs, the catch block does not execute, so e is never accessed.
When the catch executes, e always points to a valid, initialized exception object, making dereferencing (e.g., e.printStackTrace()) safe. No risk of uninitialized or dangling reference.
Actual behavior:
Infer reports: "uninitialized object e last assigned on line 9 could be dangling and is dereferenced or freed at line 10."
Description
Infer incorrectly reports a "Dangling Pointer Dereference" error for the exception parameter e in a catch block of a try-with-resources statement, claiming it is an "uninitialized object" that could be dangling when dereferenced. This is a false positive, as Java's exception handling semantics ensure the parameter is always initialized by the JVM when the catch block executes.
Expected behavior:
No DANGLING_POINTER_DEREFERENCE should be reported because:
The catch parameter e is implicitly initialized by the JVM (per JLS §14.20) when an IOException is thrown from the try block (e.g., from FileReader constructor, readLine(), or implicit close()).
If no exception occurs, the catch block does not execute, so e is never accessed.
When the catch executes, e always points to a valid, initialized exception object, making dereferencing (e.g., e.printStackTrace()) safe. No risk of uninitialized or dangling reference.
Actual behavior:
Infer reports: "uninitialized object e last assigned on line 9 could be dangling and is dereferenced or freed at line 10."