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.
Examine the following private static boolean test() throws IOException { InputStream in; try { in=System.in; } catch (Throwable T) { System.exit(0); } return in.available() == 0; } There is a "variable in might not have..." error on the "return in.ava..." statement that should not be there, as you can se the System.exit call will make that just not happening. There is a simple workaround for this and that is to place a "return" statement after the System.exit call or put an "in=null" statement in the catch part. Not sure if this is an error in NB or in JAVAC, if it is in JAVAC please feel free to file a bug.
Sorry, I filed the wrong example, this is the correct one... public boolean test() throws IOException { InputStream in=null; try { in=System.in; } catch (Throwable T) { System.exit(0); } if (in.available()!=0) { } } And the warning is "Dereferencing possible null..." and as in the previous example that could never happen, also here the workaround is a return-statement in the catch section
For the compile-time error: I am sorry, but this is not a bug in neither NetBeans or javac: this behaviour is mandated by the Java Language Specification (Chapter 16 - Definite Assignment). In Java, the compiler must produce compile-time errors exactly as specified by the specification. So this would require a change in the JLS - and I personally don't believe such a change would would repay itself: either it would be hardcoding System/Runtime.exit, which I think would bring only a marginal benefit, or something more complex would be devised (e.g. a way to mark method as never finishing normally), which would probably take massive effort to specify (even though the actual diff in the spec could be relatively small). So I am not going to suggest such a change in the spec - feel free to do so yourself, though. For the warning: I'll take a look - but sounds more like an enhancement to know about methods that never complete normally.
I actually agree,but System.exit is kind'o special and that IMHO mandates some extravagant handling. As for the error that is an error, but I think NB is a tool that should be able to recognize this, not sure but I think there are some places where similar structuring is detected and dealt with... As of filing a change in JLS, I have to think about that, some type of @tagging perhaps...
(In reply to comment #3) > I actually agree,but System.exit is kind'o special and that IMHO mandates some > extravagant handling. As for the error that is an error, but I think NB is a > tool that should be able to recognize this, not sure but I think there are some > places where similar structuring is detected and dealt with... > As of filing a change in JLS, I have to think about that, some type of @tagging > perhaps... with "but I think..." I am reffering to the warning and not the error...
(In reply to comment #3) > I actually agree,but System.exit is kind'o special and that IMHO mandates some I don't think System.exit is that much special. Yes, it may stop the VM - but, it may simply throw a SecurityException instead of shutting down the VM (for bigger/modular applications, one typically cannot simply call System.exit). And various frameworks may define similar methods that ultimately shutdown the VM (LifecycleManager.exit, in case of the NB platform). > extravagant handling. As for the error that is an error, but I think NB is a Sorry, but I don't think that "kind of special" == "mandates extra handling". If a thing is used rarely (and I believe System.exit is used rarely in a context like this), that it may not be cost effective to do any extra handling. On this matter, extra handling of Assert.fail (and Assert.assertNotNull, etc) is more important, as these are used much more often. I'll see if I can reasonably special case it in the NPECheck hint, but I can't promise anything.
That would probable do... One thought tho, even if System.exit throws a security exception it would not reach the "in.ava..." code as it is never caught....
Fixed in experimental impl (no warning given); please wait for fix push until the umbrella issues closes.
*** Bug 256697 has been marked as a duplicate of this bug. ***