Community
Participate
Working Groups
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
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 ***
