Bug 177537 - Throw LinkageError's, not RuntimeException's, for uncompilable source code
Throw LinkageError's, not RuntimeException's, for uncompilable source code
Status: NEW
Product: java
Classification: Unclassified
Component: Compiler
6.x
All All
: P3 with 1 vote (vote)
: TBD
Assigned To: Dusan Balek
issues@java
:
Depends on: 177536
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-24 10:39 UTC by Jesse Glick
Modified: 2013-10-04 15:42 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

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:

    @IgnoreJRERequirement
    public static boolean isMustangOrAbove() {
        try {
            System.console();
            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

java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
....
Caused by: java.lang.RuntimeException: Uncompilable source code
        at hudson.Functions.isMustangOrAbove(Functions.java:754)
        at hudson.node_monitors.TemporarySpaceMonitor.install(TemporarySpaceMonitor.java:77)
        ... 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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo