Community
Participate
Working Groups
We found a situation in our code where the new Null-Pointer warning of Eclipse 3.2 gave a false-positive. In [1] Eclipse says that "e" can't be null. So we naivly removed the null pointer check and our application was no longer working. I have removed as much of the code as possible to find the root of the problem and ended up with this code: public void test(String p) { List<String> list = new ArrayList<String>(); Iterator<String> it = list.iterator(); while (it.hasNext()) { String e = it.next(); e.toString(); while (true) { if (it.hasNext()) // [2] e = it.next(); else e = null; if (e == null || p != null) // [3] { if (e != null) // [1] { // Do something } break; } } } } The code is total nonsense now but it demonstrates the problem. It is definetly possible that e is null in [1]. If no more elements are in the array when we reach [2] then e is set to null and the if statement in [3] resolves to true. When we trust in the warning then we remove the null pointer check [1] and end up with null-pointer exceptions because e can be null. That's exactly what caused the problem in our application after removing the null-pointer check to resolve the warning. I'm not sure what confuses the parser here. If I remove the break, the warning is gone. If I remove one of the while loops, the warning is gone, too. Sorry, that I was not able to shorten the code more.
Reproduced. Does not involve Iterator per se. The following test case illustrates the issue. Commenting out lines a or b gets rid of the problem. public class X { public void test(String p, String q, boolean b) { while (b) { String e = q; e.trim(); // a while (true) { if (b) e = q; else e = null; if (e == null || p != null) { if (e != null) { // Do something } break; // b } } } } }
This comes from the fact that we do not leverage fully the available information at the testing point. At line [1], the inner flow info tells us that e may be null or non null. Hence we should not report it to enclosing contexts as needing further verification against the 'can only be null' condition. Added NullReferenceTest # 457.
Created attachment 50898 [details] Fix plus test case. The patch essentially avoids to report a variable for checking against can only be null or cannot be null when it is both potentially null and potentially non null (the code already avoided the reporting when the variable was potentially unknown, but this was not enough).
Released for 3.3 M3.
Verified for 3.3 M3 using warm-up build I20061030-0800