Community
Participate
Working Groups
Build Identifier: M20080911-1700 The below code doesn't compile due to the javadoc comment in method 'bar'. Referencing the generic method using '@see' without the generic param seems to confuse the compiler. public class EclipseBug { public <E extends Exception> void foo(Class<E> clazz) throws E { foo(clazz); //Compile error: Unhandled exception type Exception } /** @see EclipseBug#foo(Class) BREAKS 'foo' */ public void bar() {} /** @see EclipseBug#foo(Class<E>) WORKS */ public void fooBar() {} } Reproducible: Always Steps to Reproduce: see details tested using 1.5 and 1.6 JDK compliance
Reproduced on HEAD. I will investigate this.
Build Identifier is incorrect. it should be 20090920-1017 from a download named 'eclipse-java-galileo-SR1-win32.zip'
This worked on 3.5 and is broken already at 3.5M7. Should check with 3.5 M4 & M5. Perhaps related to bug#258798 ? (even though that defect's title is about return types, it also fixed some issues with exceptions in the presence of unchecked invocations) Compare javac & eclipse behavior with the slightly modified test case: public class EclipseBug { Class c = String.class; public <E extends Exception> void foo(Class<E> clazz) throws E { foo(clazz); foo(c); } }
(1) public class EclipseBug { public <E extends Exception> void foo(Class<E> clazz) throws E { throw new Exception(); } } results in "Unhandled exception type Exception". This is because the method now throws Exception, while it is declared to handle (by throwing) 'E extends Exception'. Thus the thrown exception is more generic than the handled exceptions, resulting in an error. This situation is analogous to the one in the non generic test case below: import java.io.IOException; public class EclipseBug { public void foo(Class<IOException> clazz) throws IOException { throw new Exception(); } } (2) Now consider the test case below: public class EclipseBug { public <E extends Exception> void foo(Class<E> clazz) throws E { foo(clazz); } public void bar(Class clazz) throws Exception { foo(clazz); } } Considering the invocation of the generic method foo in bar, given the parameter clazz is of raw type, type inference leads to the conclusion that EclipseBug#foo could throw Exception and this case decays into the case (1) above. (3) Now consider the case in comment#0. While at first sight, it may appear bizarre that something inside a comment could result in a compile error somewhere else, what is happening here is very much similar to case(2). When the preference Java + Compiler + Javadoc + Process Javadoc is turned on (default) the compiler will perform structural/syntactic analysis inside the javadoc comments. The @see comment in question is treated as a java doc "method call" (JavadocMessageSend in compiler parlance) and gets analyzed the same way as an analogous method call in code (case (2)) leading to the same error. Thus this case needs to be closed as INVALID as there is no real bug here.
Verified for 3.6RC1.
