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.
| Summary: | wrong "UnusedAssignment" hint | ||
|---|---|---|---|
| Product: | java | Reporter: | vaxquis |
| Component: | Hints | Assignee: | Svata Dedic <sdedic> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 8.0.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 249320 | ||
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. reproducible Fixed in the experimental impl; wait for the umbrella issue to close. |
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).