This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
if there is a construct like the following Rectangle r = new Rectangle(4, 3); double area; boolean should = null != r; if (should) area = r.get|Height() * r.getWidth(); else area = 0d; The mentioned hint is shown; Same if the condition in the if is somewhat more complex i.e. ((null != x) && should)
I was going to report the following, but it looks like the same bug. In the following code, the "Dereferencing possible null pointer" warning is given on the toString() call, when clearly it is not possible. void testMethod(Object in, final boolean flag) { Object x = flag ? in : null; if (flag) { String xStr = x.toString(); } } (If I replace the declaration of x with "Object x = in;" then the warning goes away.)
I think this is the same situation: int pos = table != null ? table.indexOf('@') : -1; if (pos > 0) { // the following line is marked as "Dereferencing possible null pointer" String part = table.substring(pos); .... }
Created attachment 142500 [details] Another false positive
Here is another simplified example public class Main { public static void main(String[] args) { Object obj = getObject(); boolean isOkay = obj != null; if (true) { obj.toString(); } } public static Object getObject() { return "something"; } } All of the cases where this false positive is recorded share one fundamental thing in common. They all check whether the object is non-null *before* using that object in the body of an "if" statement. If this check is never done, the false positive disappears. If the check is performed in the clause of the "if" statement, it also disappears. It seems very odd that this false positive should only appear *after* specifically checking whether the object is non-null.
(In reply to rptmaestro from comment #4) > It seems very odd that this false positive should only appear *after* > specifically checking whether the object is non-null. Because it's not known whether a method's parameter *is* actually intended to contain a null value (and reporting each dereference would produce a ton of false positives), reports are suppressed *unless* the variable is checked for null-ness. If the developer writes the check, it is a sign that the parameter might eventually contain null and so all possible NPEs should be reported.
The example shown in comment #0 no longer produces a hint in dev build (most possibly fixed in the meantime). Re. comment #1 and #3: the current analyzer implementation cannot correctly handle this situation. It would have to be changed not only to track possible-null flag for each value, but for each such null/not-null flag, a condition(s) would be present which are known to be true at the time of the value creation. A very nice enhancement - but rather complex. The example given in comment #2 is most probably a WONTFIX problem; it's similar but requires the analyzer to understand even non-reference values dependencies on (not)null condition; sorry. Comment #4 requires a non-local analysis; each method would need to be analyzed if it possibly produces a null value and that possibility would be taken into account when analysing method call sites. It is very hard to tell the result if method's parameter (or obtained references) are not checked for null - every ref can be eventually null, so each method (except some specific ones, as used in the example) MAY return null. I would rather not implement such thing.
*** Bug 244424 has been marked as a duplicate of this bug. ***
*** Bug 244345 has been marked as a duplicate of this bug. ***
Situation in comment #1 and comment #3 is addressed by code being developed for #249320 *** This bug has been marked as a duplicate of bug 249320 ***
The experimental implementation covers example in the report and comment #1 - I've used the examples in unit tests. Reopening to track progress in dev version. I filed an enhancement that covers example in comment #4 (issue #256485)
Fixed in experimental impl, unit test provided. Monitor the umbrella issue for the actual commit.