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 253300 - wrong "UnusedAssignment" hint
Summary: wrong "UnusedAssignment" hint
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 8.0.2
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks: 249320
  Show dependency tree
 
Reported: 2015-07-03 17:05 UTC by vaxquis
Modified: 2015-11-13 11:35 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 vaxquis 2015-07-03 17:05:24 UTC
the snippet showing the bug follows:

    public enum SomeEnum {
        ONE, TWO
    }

    public boolean method () {
        SomeEnum someEnum = SomeEnum.ONE;
        boolean flag = true;
        if ( 1 > 0 ) {
            switch ( someEnum ) {
                case ONE:
                    flag = false; // UnusedAssignment raised here
                    break;
                case TWO:
                    throw new RuntimeException();
            }
        }
        return flag;
    }

As you can easily see, the flag will be set to false by the statement, proving that it *isn't* unused, and then returned. Actually, the unused assignment is the initializer, but it requires the "1>0" condition to be changed to simply "true" to get the proper warning on it. Also, even then the 'flag = false' is marked as unused (while it's obviously used).

Note that commenting out the "if" completely makes the bug disappear, as well as commenting out the exception. I suspect the parser "sees" the exception as a terminating point and somehow "skips" the "break;" between, "seeing" the "flag=false" operation as preceding the throw (which is not the case).
Comment 1 vaxquis 2015-07-03 17:10:09 UTC
Note that IMO the main bug is not the fact that there ain't a warning with respect to constant comparisons nor the unused initalizer as the result (although I guess it should/could probably raise both "unused assignment" in intializer and "constant-result comparison" on the comparison itself), since that's quite an expectation from a static parser. OTOH, misleading warning is the real problem here. It took me about an hour to triple-check my code if the op is indeed used despite the warning.

tl;dr Lack of warnings is not good, but I reckon a warning on completely good code is even worse.
Comment 2 Jiri Prox 2015-07-07 13:34:15 UTC
reproducible
Comment 3 Svata Dedic 2015-11-13 11:35:19 UTC
Fixed in the experimental impl; wait for the umbrella issue to close.