Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340486 - [1.7][compiler] Missing error in multi catch scenario
Summary: [1.7][compiler] Missing error in multi catch scenario
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-19 08:30 EDT by Srikanth Sankaran CLA
Modified: 2011-08-05 02:54 EDT (History)
2 users (show)

See Also:

Attachments
Patch under test (9.87 KB, patch)
2011-05-11 06:01 EDT, Srikanth Sankaran CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Srikanth Sankaran CLA 2011-03-19 08:30:52 EDT 
(1) Reading the latest version of spec, it would appear
that the following program should not compile:


import java.io.FileNotFoundException;
import java.io.IOException;

public class X {
	public static void main(String [] args) {
		try {
			throw new FileNotFoundException();
		} catch(FileNotFoundException | IOException e) {
			
		}
	}
}

The multi catch types must be disjunctive and the order should not matter.
(c.f the section on normalization) However javac 7b131 compiles this as
does eclipse.

(2) Perusing some of the associated material, it looks like:

import java.io.IOException;
import java.io.FileNotFoundException;
public class X {
	public static void main(String [] args) {
		try {
			throw new FileNotFoundException();
		} catch (FileNotFoundException ex) { 
		}
		catch (IOException ex) {
		}
	}
}

should not compile. Again it compiles with 7b131 and in eclipse. In the
latter it generates a warning about unreachable catch block.
Comment 1 Srikanth Sankaran CLA 2011-03-19 08:32:15 EDT 
These are not for immediate action. But we need to
get the spec clarified and also track javac changes.
Comment 2 Srikanth Sankaran CLA 2011-03-28 01:44:03 EDT 
(In reply to comment #1)
> These are not for immediate action. But we need to
> get the spec clarified and also track javac changes.

Nothing has changes as of 7b135.
Comment 3 Srikanth Sankaran CLA 2011-04-28 05:46:30 EDT 
(In reply to comment #0)
> (1) Reading the latest version of spec, it would appear
> that the following program should not compile:

[...]

> The multi catch types must be disjunctive and the order should not matter.
> (c.f the section on normalization) However javac 7b131 compiles this as
> does eclipse.

This code is rejected by javac 7b138. So this item is not a gray
area anymore. Our reading of the spec is matched by javac.

> (2) Perusing some of the associated material, it looks like:

[...]
 
> should not compile. Again it compiles with 7b131 and in eclipse. In the
> latter it generates a warning about unreachable catch block.

This code elicits a new warning about unreachable catch block from javac
7b138. Eclipse already emits this warning, so we are good.
Comment 4 Srikanth Sankaran CLA 2011-05-11 06:01:48 EDT 
Created attachment 195320 [details]
Patch under test
Comment 5 Srikanth Sankaran CLA 2011-05-11 07:05:12 EDT 
Released in BETA_JAVA7 branch.
Comment 6 Olivier Thomann CLA 2011-06-28 09:41:45 EDT 
For comment 0 (2), do we need to emit the warning also in source 1.6 ?

Looks good. Verified.
Comment 7 Srikanth Sankaran CLA 2011-06-28 11:27:56 EDT 
(In reply to comment #6)
> For comment 0 (2), do we need to emit the warning also in source 1.6 ?

We already do that (even on HEAD).