Bugzilla – Full Text Bug Listing
| Summary: | [1.7][compiler] Compilers fails to compute precisely rethrown types | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Srikanth Sankaran <srikanth_sankaran> | ||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | amj87.iitr, Olivier_Thomann, satyam.kandula, stephan.herrmann | ||||
| Version: | 3.7 | Flags: | satyam.kandula:
review+
|
||||
| Target Milestone: | 3.7.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I'll follow up. Created attachment 195467 [details]
Patch under test
Here is something else that is weird:
public class X {
X() throws Exception {
try {
throw (Throwable) new Exception();
} catch (Exception e) {
throw e; // <<<<---------------- here
} catch (Throwable e) {
}
}
}
On this program eclipse reports an error "Unhandled exception type Throwable" (!!!)
(In reply to comment #2) > Created attachment 195467 [details] > Patch under test Passes all tests. Released in BETA_JAVA7 branch. Satyam, please review the patch, TIA. For the problem reported in comment# 3 I have raised a separate bug 345579 as it seems to be unrelated. +1. The changes are good. Verified using "Eclipse Java Development Tools Patch for Java 7 Support (BETA) 1.0.0.v20110623-0900 org.eclipse.jdt.patch.feature.group Eclipse.org" (In reply to comment #0) > public class X { > X() { > try { > zoo(); > } catch (EOFException e) { > } catch (FileNotFoundException e) { > } catch (Exception e) { > throw e; > } > } > > void zoo() throws FileNotFoundException, EOFException { > } > } I must admit it took me a while to figure out what exceptions might be caught by the last catch block. From my current understanding that block is now semantically the same as saying "catch (RuntimeException e) {throw e; }", right? If that's so, have you considered raising a warning that the catch block could be made more precise by using RuntimeException? IMHO, this would make clearer why throwing Exception is now legal without declaring. (In reply to comment #7) > I must admit it took me a while to figure out what exceptions might be caught > by the last catch block. From my current understanding that block is now > semantically the same as saying "catch (RuntimeException e) {throw e; }", > right? Yes, it is semantically equivalent to this. > If that's so, have you considered raising a warning that the catch block > could be made more precise by using RuntimeException? IMHO, this would make > clearer why throwing Exception is now legal without declaring. Basically, you are telling that whenever a more general exception is getting caught, we should warn the user. If we ever do it, we should turn it off by default and the number of warning options are increasing :(. Do you think it will really help the user? It is probably worthwhile discussing it in a new bug. |
TOP of BETA_JAVA7 branch: The following program fails to compile with eclipse while it should. JDK 7b138 compiles it alright. import java.io.EOFException; import java.io.FileNotFoundException; public class X { X() { try { zoo(); } catch (EOFException e) { } catch (FileNotFoundException e) { } catch (Exception e) { throw e; } } void zoo() throws FileNotFoundException, EOFException { } }