Bug 153494

Summary: 'Unused import' error hides 'uncaught exception', impeding use of 'Surround with try/catch' autofix
Product: [Eclipse Project] JDT Reporter: Gordon Henriksen <malanon>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: RESOLVED WORKSFORME QA Contact:
Severity: enhancement    
Priority: P3    
Version: 3.2   
Target Milestone: 3.2   
Hardware: Macintosh   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description Gordon Henriksen CLA 2006-08-10 17:00:47 EDT
This particular behavior frequently interrupts my workflow.

1. Under Preferences > Java > Compiler > Errors/Warnings > Unnecessary code, set 'unused import' to 'error'.
2. Create these 2 classes:

package test2;
public class Bar {
	public static class BarException extends Exception {/* empty */}
	public static void bar() throws BarException {
		if (true)
			throw new BarException();
	}
}

package test1;
import test2.Bar;
import test2.Bar.BarException;
public class Foo {
	public static void foo() throws BarException {
		 Bar.bar();
	}
}

3. Build. Observe success.
4. As if in preparation of handling the BarException, make this edit:
-	public static void foo() throws BarException {
+	public static void foo() {
4. Build. Observe: only 1 error: 'the import test2.Bar.BarException is never used' (a discretionary error).
-- then either: --
5a. Return to Preferences and set 'unused import' back to warning.
6a. Build. Observe: The error from step 4 is now a warning, and is joined by the 'Unhandled exception type Bar.BarException'.
-- or: --
5b. Make this edit:
-import test2.Bar.BarException;
6b. Build. Observe: The 'Unhandled exception type' error appears now, only after the import necessary to catch it was deleted...

Desired behavior: At step 4, both errors should be presented, as they are if the 'unused import' warning is not configured as an error.
Comment 1 Frederic Fusier CLA 2006-08-11 03:49:00 EDT
Your enhancement is already implemented :-)

Open project properties and go to Java->Building preferences page. Then unselect check-box "Treat -configurable errors- like fatal errors i.e. compiled is not executed". Rebuild your project and then you'll see the 2 errors.

You can also set this behavior to your entire workspace using Preferences dialog and go to Java->Compiler->Building page...
Comment 2 Gordon Henriksen CLA 2006-08-15 16:15:28 EDT
D'oh! Thanks for the pointer. Out of curiousity, what's the advantage of this setting being/defaulting off?
Comment 3 Maxime Daniel CLA 2006-08-22 04:55:10 EDT
(In reply to comment #2)
> D'oh! Thanks for the pointer. Out of curiousity, what's the advantage of this
> setting being/defaulting off?
> 
From the discussions I recall, promoting a warning to an error is a user decision that basically says exactly that: (s)he wants the problem to be reported as an error. The refinement of having some of these errors considered as not offending enough to prevent the resulting class files to run came later on and basically adds complexity to the picture at the conceptual level, hence the current default.

Comment 4 Eclipse Webmaster CLA 2007-07-29 09:20:44 EDT
Changing OS from Mac OS to Mac OS X as per bug 185991