Community
Participate
Working Groups
Null reference analyzer raizing a false positive on the following code: public static void main(String[] args) { String v = System.getProperty("test"); if(v==null) { System.exit(0); } if(!v.startsWith("a")) { System.err.println("### B.main() "+v); } } Basically System.exit() here should have the same effect as return or trow.
Not really if you follow the standard rules for definite assignment etc... System.exit(...) is just another message send. The nullref analysis is consistent with our conservative data flow analysis in this respect.
If you want to make it obvious to the compiler, then write: public static void main(String[] args) { String v = System.getProperty("test"); if(v==null) { System.exit(0); return; // cannot be reached for real due to #exit(...) call } if(!v.startsWith("a")) { System.err.println("### B.main() "+v); } }
(In reply to comment #2) Philippe, I don't think it is acceptable to add return after System.exit(). I'd agree that using system.exit() in first place is moveton, but this particular warning appeared in some legacy code I am not allowed to touch and yet I see this warning. I believe it is reasonable to take into account that stis call can terminate JVM execution.
This might well imply a separation between the current flow analysis and the null flow analysis, which is due to be expensive at runtime. Currently, the null analysis leverages the knowledge the flow analysis has of dead branches. But the latter is commanded by the JLS, which is fairly conservative and doesn't know about System.exit(). This hence implies that we introduce 'null only dead branches', and recraft the whole logic. I would rather not do this without considering other needs for refactoring as well.
Post 3.2.
Since this one is due to be expensive, I'd rather leave it to more comprehensive static analysis tools and close it as WONTFIX. Philippe, what do you think?
Reopening as P5 (since RESOLVED LATER is deprecated).
*** Bug 193972 has been marked as a duplicate of this bug. ***
(In reply to comments 4,5 and 6) How about adding System.exit(), Runtime.getRuntime().exit() and Runtime.getRuntime().halt() as always throwing an exception to the normal flow analysis, marking code behind calls as dead code? The assertion that these methods methods don't return normally should be true for the foreseeable future.
API specification from Sun specifies clearly that System.exit never returns normally: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#exit(int) In addition to this, there is no way to return a specific error code and exit the JVM, so you can't really replace the System.exit() calls with something else. So in light on these, System.exit() should have just the same effect as throw.
This problem makes the "potential null pointer access" warning give false positives. Switching off that warning for now and adding my vote: https://bugs.eclipse.org/bugs/votes.cgi?action=show_user&bug_id=132875#vote_132875
Eclipse really lost the momentum. After encountering this bug, I somehow knew there is already a bug open for it. and I somehow knew no one gives a shit. the bug is now over 7 years old.
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.
