Bug 41314 - unnecessary warning with multiple catches in a try statement
Summary: unnecessary warning with multiple catches in a try statement
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.0 M3   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-08 04:50 EDT by Andre Meyer CLA
Modified: 2003-08-19 10:59 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Meyer CLA 2003-08-08 04:50:52 EDT
The editor displays a warning when there are multiple catch blocks for the same
try statement. However, this is allowed and often used style.
Of course, the exceptions need to be in the "correct" order such that they can
be caught properly.
Comment 1 Olivier Thomann CLA 2003-08-11 08:44:07 EDT
Could you please provide a test case that shows this behavior? The "correct"
order should already be checked. It should not complain if the "correct" order
is used.
Comment 2 Olivier Thomann CLA 2003-08-11 10:13:12 EDT
From mail message:
My example uses an external library: JADE, the API is at
http://jade.cselt.it/doc/api/index.html.

The code is here:
===========================
		 try
		 {
		 		 ...
		 }
		 catch(StaleProxyException spe)
		 {
		 		 spe.printStackTrace();
		 }
		 catch(ControllerException ce)
		 {
		 		 ce.printStackTrace();
		 }
===========================
The second catch is yellow with a warning "Catch block is hidden by another
one in the same try statement"

When I change the order of catches, the second one(StaleProxyException then)
gives an error message "Unreachable catch block".

Please keep the discussion here. It is easier to follow the thread. Thanks.
Comment 3 Olivier Thomann CLA 2003-08-11 13:03:25 EDT
I download the source and compiled it, but I didn't find this specific error.
Two things to check:
1) Are you sure that the ControllerException is not already handled in the try
block.
Something like:
try {
    ...
    try {
      ....
    } catch(ControllerException  e) {
      ....
    }
    ....
} catch(StaleProxyException e) {
   ....
} catch(ControllerException e) {
    ....
}

2) Try to remove the second catch. The problem could be that this catch block is
never reach because the only exception that could be thrown in the try block is
a StaleProxyException.

Let me know if your code matches one of the cases.
Comment 4 Olivier Thomann CLA 2003-08-11 15:40:22 EDT
Here is a small test case that might reproduce what you have:

class E1 extends Exception {
	
}

class E2 extends E1 {
}

public class A {

	static void foo() throws E2 {
	}
	
	public static void main(String[] args) {
		try {
			foo();
		} catch(E2 e) {
		} catch(E1 e) {
		}
	}
}

The compiler reports:
Compiled 19 lines in 2500 ms (7.6 lines/s)
3 .class files generated
----------
1. WARNING in D:\temp\A.java (at line 17)
	} catch(E1 e) {
		}
	              ^^^^^^
Catch block is hidden by another one in the same try statement
----------
1 problem (1 warning)

The reason is that the second catch cannot be reached when the first catch is
there. It is not strictly unreachable in the JLS meaning, because a compatible
exception can be thrown inside the try block.
You might try to see if we can improve such a diagnosis, but according to what I
tried, something must be wrong with your try statement.
Besides this warning, I found lot of suspicious warnings compiling the JADE code
using the Eclipse compiler (assignment with no effects, lot of non-static access
and other warnings).
Comment 5 Andre Meyer CLA 2003-08-19 07:22:57 EDT
After trying lots of things based on your remarks, the following seems to be 
the cause: I have a comment in my code (/**- ... /**/). When the first part is 
removed the warning disappears! There is no real reason I can think how the two 
things a re connected. Thus, the bug must be somewhere else, such as the 
interpretation of comments in this fashion. Here is the full code of my class. 
If you remove the line with /**- the warning goes away. Reinserting it brings 
the warning back. You will need a class UserAgentGenerator (subclass of 
jade.core.Agent).


package simedia;

import jade.core.Runtime;
import jade.core.Profile;
import jade.core.ProfileImpl;
import jade.wrapper.*;

public class Mediashelf
{
	private MainContainer mc;
	
	public Mediashelf()
	{
		Agent myAgent = null;
		
		try
		{
			// Get a hold on JADE runtime
			Runtime rt = Runtime.instance();
			rt.setCloseVM(true);
			// Launch a complete platform on the 8888 port
			// create a default Profile 
			Profile pMain = new ProfileImpl(null, 8888, null);
			mc = rt.createMainContainer(pMain);
/**-
			// starting the RMA GUI
			AgentController rma = mc.createNewAgent
("rma", "jade.tools.rma.rma", new Object[0]);
			rma.start();
/**/
			// create UserAgentGenerator
			myAgent = (Agent)mc.createNewAgent
("UserAgentGenerator", UserAgentGenerator.class.getName(), new Object[] {  });
			myAgent.start();
		}
		catch(StaleProxyException spe)
		{
			spe.printStackTrace();
		}
		catch(ControllerException ce)
		{
			ce.printStackTrace();
		}
	}

  /**
   * This method starts the Mediashelf
   */
	public static void main(String[] args)
	{
		new Mediashelf();
	}
}
Comment 6 Olivier Thomann CLA 2003-08-19 10:59:48 EDT
This is not a bug.
In your code, the first start() invocation (in comment)
// starting the RMA GUI
			AgentController rma = mc.createNewAgent
("rma", "jade.tools.rma.rma", new Object[0]);
			rma.start();

throws a ControllerException whereas the second start() invocation:
 // create UserAgentGenerator
			myAgent = (Agent)mc.createNewAgent
("UserAgentGenerator", UserAgentGenerator.class.getName(), new Object[] {  });
			myAgent.start();
throws only a StaleProxyException. So when the two start() invocations are 
called, the two catch clauses are reachable, but when the first one is 
commented, the second catch clause is hidden by the first catch clause.
Hope this explanation help to understand the code.
Close as INVALID.