Bug 9088 - Unreachable catch block when error in referenced class's fields
Summary: Unreachable catch block when error in referenced class's fields
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 M3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-04 23:19 EST by Nick Edgar CLA
Modified: 2002-02-11 04:52 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2002-02-04 23:19:21 EST
Build 20020129

- I had a legitimate compilation error in a field initializer in WorkbenchPage:
    private SelectionService selectionService = new SelectionService();
I had marked SelectionService as abstract, so this was expected.

- I got an unreachable catch block in the following code in WorkbenchWindow:
		WorkbenchPage result = null;
		try {
			result = new WorkbenchPage(this, pageMem, input);
			pageList.add(result);
			pageListeners.firePageOpened(result);
			addShortcut(result);
		} catch (WorkbenchException e) {
			WorkbenchPlugin.log("Unable to restore perspective - 
constructor failed.");//$NON-NLS-1$
			continue;
		}

This was not expected.

It looks to me that WorkbenchPage got a problem constructor due to the error 
with its field, but that it didn't declare any exceptions.

Is this the intended behaviour?
Comment 1 Nick Edgar CLA 2002-02-04 23:20:25 EST
The signature of the WorkbenchPage constructor is:
public WorkbenchPage(WorkbenchWindow w, IMemento memento, IAdaptable input) 
	throws WorkbenchException

None of the other calls in the catch block above throw any checked exceptions.
Comment 2 Olivier Thomann CLA 2002-02-05 16:28:56 EST
I think this is due to the fact that the problem constructor created when an exception is reported 
in a field initializer doesn't contain the right thrown exceptions.
Comment 3 Olivier Thomann CLA 2002-02-05 16:38:30 EST
A simpler test case is:

[package prs;

import java.io.IOException;

public class 
Test1 {
	
	String s = 3;
	
	Test1() throws IOException {
	}

}]
[package 
prs;

import java.io.IOException;

public class Test2 {

	public void foo() 
{
		try {
			Test1 t = new Test1();
			System.out.println();
		} catch(IOException e) 
{
			e.printStackTrace();
		}
	}
}]

The problem is gone if you replace s = 3; with s = 
"3";. I will investigate this case. It seems that we might want to change the way we generate 
problem constructor and problem methods.
Comment 4 Olivier Thomann CLA 2002-02-05 16:44:53 EST
In order to get it, the second file has to be compiled using the first class from binary and not from 
source. If both classes are compiled in the same time, there is no problem.
Comment 5 Olivier Thomann CLA 2002-02-05 17:20:58 EST
In fact the fix is quite obvious. We never generated the exception attributes for the problem 
constructors, but we did for the problem methods. I added the following attributes for problem 
constructors:
 - exception
 - deprecated
 - synthetic
I added a call to 
generateMethodInfoAttribute(MethodBinding). This will add the right attributes 
automatically.
Fixed and released in HEAD. 
Comment 6 Olivier Thomann CLA 2002-02-05 17:26:53 EST
Fixed.
Comment 7 Olivier Thomann CLA 2002-02-06 12:29:37 EST
Regression test added.