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 230195 - smarter "Dereferencing possible null pointer" hint?
Summary: smarter "Dereferencing possible null pointer" hint?
Status: RESOLVED DUPLICATE of bug 249320
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.4
Hardware: PC Mac OS X
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-23 17:16 UTC by athompson
Modified: 2016-07-13 13:29 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description athompson 2013-05-23 17:16:45 UTC
Disclaimer: I'm having a bad brain day, so if my logic is flawed let me know.

I have the following snippet of code:


        if (!collection && value == null) {
            // NULL in, NULL out.
            out = null;
        } else if (collection && value == null) {
            // If a Collection is expected but the value is NULL, just create an
            // empty Collection.
            out = new LinkedList<Object>();
        } else if (collection && String.class.equals(valueType)) {
            // If a Collection is expected but the value is a String, then the
            // Collection values must be parsed from the String.
            Collection<Object> collectionValues = new LinkedList<Object>();
*           for (String s : ((String)value).split("\\|")) {
                ...
            }
            out = collectionValues;
        }

In the line marked with an asterisk, the "split" method is underlined with the hint, "Dereferencing possible null pointer". I think you can always use the below logic to infer that "value" cannot be NULL there, which should be easy to implement (I assume so but I haven't looked at how the code works):

If you're evaluating an "else if" block, and if all but one of the conditions in a previous "if"/"else if" block in the chain are shared by the block being evaluated, then you can infer that the opposite of the remaining condition in the previous block must be true for the block being evaluated.

To make the logic simpler, all conditions should be rewritten to use only ANDs.

Ow, my brain hurts...
Comment 1 athompson 2013-05-23 17:37:15 UTC
Come to think of it, you would have to rewrite OR logic using NOT ANDs--that is:

  (A or B) and C  -->  not(not(A) and not(B)) and C

...so it gets uglier in a hurry. I guess the better approach is to apply either that rule or the OR version of the rule and recursively solve (I think). Okay, it's not as easy as I thought...
Comment 2 athompson 2013-05-23 17:40:19 UTC
I guess the simplest approach is to just not bother evaluating anything inside parenthesis (and mixing ANDs and ORs implies parenthesis).
Comment 3 athompson 2013-05-23 18:00:24 UTC
Actually, this may be a bug. The code snippet doesn't show an error unless this line is before it:

            Class<?> valueType = value != null ? value.getClass() : null;

...so I guess that null check is not being overridden by the null check in the IF/ELSE IF chain.
Comment 4 Martin Balin 2016-07-07 07:31:29 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss
Comment 5 athompson 2016-07-07 16:20:16 UTC
Still there but not worth the effort...
Comment 6 Svata Dedic 2016-07-13 13:29:51 UTC
Reviewing status after bulk issue cleanup. Actually a duplicate of 249320

*** This bug has been marked as a duplicate of bug 249320 ***