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.
[ BUILD # : 20051108 ] [ JDK VERSION : 1.6 ] Consider the following code: Attributes attrs = ldapConn.getAttributes(buildUserDN(), new String[]{"userPassword"}); attrs.put("userPassword", txSenhaNova.getText()); NB warns, about the NamingException being throw, then applying "Surround with try/catch", transform to: try { attrs = ldapConn.getAttributes(buildUserDN(), new String[]{"userPassword"}); } catch (NamingException ex) { ex.printStackTrace(); } attrs.put("userPassword", txSenhaNova.getText()); NB warns "variable attrs might not have been initialized". The correct way, is to put the attrs = null, like: Attributes attrs = null; try { attrs = ldapConn.getAttributes(buildUserDN(), new String[]{"userPassword"}); } catch (NamingException ex) { ex.printStackTrace(); } attrs.put("userPassword", txSenhaNova.getText());
> he correct way, is to put the attrs = null ... Only one side of thing. You are definitely right if you want to have your source compilable. But bear in mind, that such a behaviour will allow to compile the source code and user will probably not read the source. In your example, you risk the NPE exception in attrs.put(). When we were implementing this, we decided to leave semantic error - then, you can invoke 'initialize variable' hint on error line and you will get Attributes attrs = null; - but it is user action, so we can be sure that user knows what he do. He can also move the underlined line to try block. In my opinion, current behaviour is better, but I will wait for other opinions.
Thanks for the explanation. I understand your point, but from a practial point of view, I prefer to intialize the variable to null. What do you think about this proposal: Create and initialize the variable to null and put a comment warning the user about a possible NPE, at the line after the try/catch scope, like this: Attributes attrs = null; try { attrs = ldapConn.getAttributes(buildUserDN(), new String[]{"userPassword"}); } catch (NamingException ex) { ex.printStackTrace(); } // possible NPE: there is a possibility the code inside try/catch could not execute properly attrs.put("userPassword", txSenhaNova.getText());
It is possible. Unfortunately such a change should be discussed with others and cannot be implemented for 5.0, because it is too late for it. This is the reason why I changed target milestone to 'future'. Morever, seems to me like an enhancement. I is not obvious that current behaviour is incorrect. Can we change it to enhancement?
At first, the code is not compilable, because of the exception being throws, then I want to use "surround with try/catch" to make the time to compile faster, but "surround with try/catch" actually, makes the code not compilable, thus putting another manual step to make the class ready to compile.
*** Issue 68939 has been marked as a duplicate of this issue. ***
We discussed this issue and we came to the conclusion that making such code to compile is simply too dangerous. Even the comment is not enough. Uncompilable code will point the user to the problem and won't let him run the app until the bug gets fixed. Compilable code may potentionaly lead to a NPE in production code, which is way more serious problem than the local discomfort of a user doing refactoring.