Bugzilla – Full Text Bug Listing
| Summary: | [extract local] Refactoring to create local var can create new local outside "if" that tests for null, causing NPE in executed code | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Luke Hutchison <luke.hutch> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr, daniel_megert |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Of course if node.equivOrigin1.lineagePath or node.equivOrigin1.lineagePath is null, the field node.lineagePath will have the substring "null" in it after null is rendered into a string "null" by the string concat operator, but the point is it won't actually generate a NPE before refactoring, but will generate a NPE after, because node.equivOrigin1 or node.equivOrigin2 can now be null during the setting of ep1 or ep2. (In reply to comment #1) > Of course if node.equivOrigin1.lineagePath or node.equivOrigin1.lineagePath is > null, the field node.lineagePath will have the substring "null" in it after > null is rendered into a string "null" by the string concat operator, but the > point is it won't actually generate a NPE before refactoring, but will generate > a NPE after, because node.equivOrigin1 or node.equivOrigin2 can now be null > during the setting of ep1 or ep2. Moving to JDT/UI for follow up. IMO, it doesn't really make much sense to perform a full static analysis on the variable which is being extracted. This will slow down refactoring too much. *** This bug has been marked as a duplicate of bug 133559 *** |
Build Identifier: When refactoring, an expression can be moved to a position outside an if-statement that guarantees the expression cannot be null, causing NPEs. For example: Before refactoring: if (node.equivOrigin1 != null && node.equivOrigin2 != null) { node.lineagePath = "[" + node.equivOrigin1.lineagePath + "/" + node.equivOrigin2.lineagePath + "]"; } else { node.lineagePath = node.equivOrigin1 != null ? node.equivOrigin1.lineagePath : node.equivOrigin2.lineagePath; } // It is impossible for any of the above code to generate a NPE. After refactoring: String ep1 = node.equivOrigin1.lineagePath; // Can cause NPE here String ep2 = node.equivOrigin2.lineagePath; // ...or here if (node.equivOrigin1 != null && node.equivOrigin2 != null) { node.lineagePath = "[" + ep1 + "/" + ep2 + "]"; } else { node.lineagePath = node.equivOrigin1 != null ? ep1 : ep2; } // The above code can generate a NPE. This is a curly problem that is probably a little hard to catch until Eclipse gets full nullability tracing (which I understand is in general an uncomputable problem given Java's language model?). However simple cases should be caught, refactoring should never introduce bugs if at all possible... Reproducible: Always