Community
Participate
Working Groups
Build Identifier: 20100218-1602 In the following code, (1) is underlined and a following message appears: "Null pointer access: The variable ssock can only be null at this location" Which is obviously wrong. Reproducible: Always Steps to Reproduce: import java.io.IOException; import java.net.ServerSocket; public class Bug { public static void main(String[] args) { ServerSocket ssock = null; try { ssock = new ServerSocket(); while (true) { ssock.setSoTimeout(10); ssock.accept(); } } catch (IOException ioe) { try { /*(1)*/ssock.close(); } catch (Exception dontCare) {} } } }
(In reply to comment #0) > In the following code, (1) is underlined and a following message appears: > "Null pointer access: The variable ssock can only be null at this location" > Which is obviously wrong. No, the constructor can throw a IOException. So the variable can be null. Also the compiler considers the locals state before the try block is entered when accessing the catch block. I would close as INVALID. Ayushmain, any comment ?
(In reply to comment #1) > No, the constructor can throw a IOException. So the variable can be null. > Also the compiler considers the locals state before the try block is entered > when accessing the catch block. > I would close as INVALID. > Ayushmain, any comment ? The compiler actually does consider the state inside the try block as well. TO reason out why this problem occurs, I'd say that since there's an infinite loop following the statement where ssock is constructed, the compiler assumes that the only reason why we're in the catch block is because there was an exception while constructing ssock. So commenting out the while loop will give you the diagnostic that you're expecting - "Potential null pointer access". Note that we can also have a potential null pointer access diagnostic for the reported case, which will be much better, since the IOException might have come from ssock.accept() statement. Even now, if we modify the given case to add just one more statement before the while loop - 'ssock.setSoTimeout(10)', I can see the correct potential null warning. I'll investigate and see if this can be achieved without breaking anything else.
(In reply to comment #1) > (In reply to comment #0) > > In the following code, (1) is underlined and a following message appears: > > "Null pointer access: The variable ssock can only be null at this location" > > Which is obviously wrong. > No, the constructor can throw a IOException. So the variable can be null. > Also the compiler considers the locals state before the try block is entered > when accessing the catch block. > I would close as INVALID. The variable can be null, yes, but the diagnostic from the compiler is wrong: it claims the variable ssock can *only* be null at this location. See also bug 321926
This is a duplicate of bug 321926, the proposed patch at bug 321926 comment 19 does not address it yet, but it should. *** This bug has been marked as a duplicate of bug 321926 ***
Verified for 3.6.1 RC2 using Build id: M20100825-0800
Verified for 3.7M2 using build I20100909-1700.
