Bugzilla – Full Text Bug Listing
| Summary: | [1.7][compiler][multicatch] Compiler accepts type variables as catch parameter type | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Srikanth Sankaran <srikanth_sankaran> | ||||||
| Component: | Core | Assignee: | Satyam Kandula <satyam.kandula> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | amj87.iitr, Olivier_Thomann | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.7.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 192003 [details]
Proposed patch
Pulled in some checks from Argument#resolveForCatch() to DisjunctiveTypeReference#resolveType(). I haven't added the check for void array types as I couldn't find a real usecase.
Olivier, For this, I pulled some checks in Argument#resolveForCatch() into DisjunctiveTypeReference#resolveType(). There is one check for void array type that I didn't understand nor could get a testcase. Do you think we should pull in the check? (In reply to comment #2) > DisjunctiveTypeReference#resolveType(). There is one check for void > array type that I didn't understand nor could get a testcase. Do you think we > should pull in the check? No, this should actually be removed as this is checked during the resolution of the actual array type reference. So the code should not be moved to DisjunctiveTypeReference, but should also be removed from Argument#resolveForCatch(..). (In reply to comment #3) > (In reply to comment #2) > > DisjunctiveTypeReference#resolveType(). There is one check for void > > array type that I didn't understand nor could get a testcase. Do you think we > > should pull in the check? > No, this should actually be removed as this is checked during the resolution of > the actual array type reference. > So the code should not be moved to DisjunctiveTypeReference, but should also be > removed from Argument#resolveForCatch(..). Thanks Olivier, I will change resolveForCatch() also. Created attachment 192164 [details] Patch Updated patch after removing unused code in Argument.java as per comment 3. Released in BETA_JAVA7 branch Verified using Eclipse Java 7 Support(Beta) feature patch v20110623-0900. |
BETA_JAVA7 The following program compiles fine while it should not: //-----------------------8<------------------------------ public class X<T extends Exception> { public void foo(boolean bool) throws Exception { try { if (bool) throw new Exception(); else throw new NullPointerException(); } catch (T | NullPointerException e) { } } } //-------------------------8<---------------------------- The problem stems from the fact that certain checks that must be applied on the catch parameter type now get applied on the lub as opposed to everyone of the constituent disjucntive type references. See org.eclipse.jdt.internal.compiler.ast.Argument.resolveForCatch(BlockScope) and org.eclipse.jdt.internal.compiler.ast.DisjunctiveTypeReference.resolveType(BlockScope, boolean). Satyam, make sure to carry over all relevant checks