Bugzilla – Full Text Bug Listing
| Summary: | [compiler][null] Add support for @EnsuresNonNullIf | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marcel Bruch <marcel.bruch> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sebastian.zarnekow |
| Version: | 4.5.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | stalebug | ||
If if add @NonNull to the local variable I even need to suppress the null warning:
@SuppressWarnings("null")
@NonNull Bug bug = problem.getBug();
I end up with two annotations for one method call.
Looks like you want smth like http://types.cs.washington.edu/checker-framework/current/api/org/checkerframework/checker/nullness/qual/EnsuresNonNullIf.html Yes, sounds like. --- Another example where I find the null analysis behavior troubling: return p.hasBug() && !bugIds.add(p.getBug().getBugId()); This effectively forces me to turn all null analysis to warning and use @SupressWarnings or to rewrite every line that uses a similar pattern. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
I use patterns like the one below in my code: if (problem.hasBug()) { Bug bug = problem.getBug(); bug.getBugId(); ... With null analysis enabled, the compiler complains that bug might potentially be null. In that case, however, I know that bug cannot be null because of the previous problem.hasBug() check. I may work around this problem by adding an @NonNull annotation to bug - but doing this potentially hundred times in my code base is not user-friendly. I somehow should be able to specify that problem.hasBug() == true --> problem.getBug() will return a @NonNull value.