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.

Bug 177537 - Throw LinkageError's, not RuntimeException's, for uncompilable source code
Summary: Throw LinkageError's, not RuntimeException's, for uncompilable source code
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Compiler (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Dusan Balek
Depends on: 177536
  Show dependency tree
Reported: 2009-11-24 10:39 UTC by Jesse Glick
Modified: 2013-10-04 15:42 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-11-24 10:39:24 UTC
See setup in bug #177536 for background. Assuming that the "Uncompilable source code" throwable were in fact thrown during code execution (in this case it probably would not be), it is inappropriate to use RuntimeException for this purpose. For example, Functions contains:

    public static boolean isMustangOrAbove() {
        try {
            return true;
        } catch(LinkageError e) {
            return false;

This works correctly when the code is compiled against JDK 6 and run on JDK 5 or 6. But when the code is compiled by the NetBeans internal javac running on JDK 5, we get

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.RuntimeException: Uncompilable source code
        at hudson.Functions.isMustangOrAbove(
        at hudson.node_monitors.TemporarySpaceMonitor.install(
        ... 17 more

In other words, the RE is being thrown right past the catch block and breaks surrounding code which is otherwise written to deal with the situation gracefully.

The NB-generated classes should instead throw LinkageError for uncompilable source code, just like the JRE would do if the source code were compilable against some alternate classpath but fails to link against the current runtime.

(Ideally generated code would throw an appropriate subtype: for example, in this case a NoSuchMethodError would be perfect. NoClassDefFoundError would be appropriate for missing types, etc. But just throwing plain LinkageError would be a good start.)
Comment 1 Jan Lahoda 2009-11-27 05:11:56 UTC
Well, although LE may be appropriate for un-resolvable method, it is not appropriate,
IMO, for code like "1+;" (there is no linkage problem in this statement, and the LE would be
throw when the execution would reach the point of such a statement). Using both LE and RE
would be quite confusing for users (and the rest of the IDE too). So I am not sure if throwing
LE is a good idea.
Comment 2 Jesse Glick 2009-11-27 09:40:24 UTC
For syntax errors, just throw whatever subclass of LinkageError is most appropriate - probably ClassFormatError, maybe VerifyError. These are all assignable to LinkageError even though they do not involve class -> class dependencies as such, i.e. LinkageError really means "some fatal problem loading classes", which is exactly what should be used for erroneous code.
Comment 3 _ gtzabari 2013-10-04 15:42:13 UTC
Makes sense to me.