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.

Bug 255953 - Hint "Dereferencing possible null pointer" incorrectly influenced by if statement
Summary: Hint "Dereferencing possible null pointer" incorrectly influenced by if state...
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 8.0.2
Hardware: PC Windows 8.1
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks: 249320
  Show dependency tree
 
Reported: 2015-10-15 15:13 UTC by in-ws5
Modified: 2015-11-13 12:26 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description in-ws5 2015-10-15 15:13:01 UTC
Consider the following code:

public class A {

    public static void main(String... args) throws Exception {

        final Object o = getObject();

        if (o == null) {

        }

        if (true && o == null) {

        } else {
            System.out.println(
                    o.toString()
            );
        }
    }

    public static Object getObject() {
        return new Object();
    }
}


On the line where the object's toString() method is called, the hint "Dereferencing possible null pointer" is given.

Considering the "if-else-if" construction, o could never be null on the line where the hint is given.

However, removing the first "if" statement with the expression "o == null", somehow removes the hint as well.

It seems like a preceding if statement can unjustly affect the editor's state on determining whether the object could be null, as if the situation is too complex to be able to correctly determine this.
Comment 1 Svata Dedic 2015-10-16 21:25:39 UTC
The IDE cannot report all possible NPEs; annotations asserting non-nullness (i.e. @NonNull) are not standard and those defined by various IDEs and libraries are not widely used.

Therefore the IDE originally assumes an "all is good" state for a variable, but as soon as it encounters a check for null (which indicates the programmer supposes the value MAY become null under certain conditions) it start to report its dereferences. So the behaviour change depending on the 1st if is OK.

Strictness of the check could be configurable (i.e. assume all returns not asserted with @NonNull are nullable) but I doubt this mode should be the default one.
Comment 2 Svata Dedic 2015-11-13 12:26:13 UTC
Fixed in the new implementation. Although the optional 'strict' mode (potential null for all non-annotated variables/parameters) is not implemented, the implementation understands that because of if-condition, o can never be null in the else branch.
Wait for the umbrella issue to close.