| Summary: | [compiler][null] null reference analysis: false positive in try/finally | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Görge Albrecht <eclipse> |
| Component: | Core | Assignee: | Maxime Daniel <maxime_daniel> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.2 | ||
| Target Milestone: | 3.2 M6 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
Added class NullInfoRegistry to track potential changes made within the try blocks. Added test cases NullReferenceTest # 513 to 516 to illustrate the new behavior. (The trick is the following: since a try block may be exited at any point, any operation upon a reference within it mitigates whatever we know for sure, except if all operations are congruent - aka, null, null, null or non null, non null... This unique behavior motivates the introduction and use of NullInfoRegistry. Note that this class does not represent the null information at a precise point in the flow, but collects all null related operations effects for a given context.) Verified for 3.2 M6 using warm-up build I20060327-0010. Verified in 3.2M6. Mark as closed. Thanks. |
In the following code the "null reference analysis" produces a false positive: 1: Object o = null; 2: try { 3: o = createObject(); 4: System.out.println(o.toString()); 5: return o; 6: } finally { 7: if (o != null) { 8: System.out.println(o.toString()); 9: } 10: } If createObject() in line 3 returns null, "o.toString()" in line 4 raises a NullPointerException. Further on the finally block is executed with "o" being null. Without "interprocedural analysis" the "taint" should be removed from "o". Besides from this bug, it's a great feature. Thanks!