Community
Participate
Working Groups
3.6. Assignment before exception happens not honored in analysis. I'm reporting this as one bug because it's probably the same issue/fix. 1. may not be initialized problem reported: void bug() { String s; try { s= ""; throw new IOException(); } catch (IOException e) { } s.toString(); } 2. potential null pointer access reported: void bug() { String s= null; try { s= ""; throw new IOException(); } catch (IOException e) { } s.toString(); }
Note that case 1 is not a bug. Javac reports the same error, and its compliant with JLS section on definite/indefinite initialization. So this error is correct. As for case 2, s may be null incase an unchecked, uncaught exception occurs here. The warning is also consistent with the "may not be initialized error". Since we dont want to honour the assignment s = "" always, we shouldn't infer that s will always be non null. So this seems correct to me. Olivier/Srikanth, whats your opinion?
From a user/coder perspective I don't see what's different in the try-catch example compared to: void bug() { String s; s= ""; s.toString(); } where we don't issue the warning.
(In reply to comment #2) > From a user/coder perspective I don't see what's different in the try-catch > example compared to: Well the compiler has to comform with the JLS, and in many cases, the specs are pretty much counter-intuitive. So, in some cases such as these, even when we can make the compiler smarter, the specs hold us back.
(In reply to comment #3) > (In reply to comment #2) > > From a user/coder perspective I don't see what's different in the try-catch > > example compared to: > > Well the compiler has to comform with the JLS, and in many cases, the specs are > pretty much counter-intuitive. So, in some cases such as these, even when we > can make the compiler smarter, the specs hold us back. That might be true for the first case (didn't read the spec) but not for the second.
(In reply to comment #4) > > Well the compiler has to comform with the JLS, and in many cases, the specs are > > pretty much counter-intuitive. So, in some cases such as these, even when we > > can make the compiler smarter, the specs hold us back. > That might be true for the first case (didn't read the spec) but not for the > second. http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html#16.2.15 I would say both cases are consistent. If we report that s may not have been initialized in the first case, we must also report that a potential null pointer exception is possible in case 2.
I disagree. The potential null problem is our invention and we can be more user-friendly than the spec.
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.
