Changing exception clause in method signature when overwriting a method

Question

Hi,
I stumbled upon a situation by accident and am not really clear on the details surrounding it. A short description:
Say there is some API with interfaces Foo and Bar as follows:
public interface Foo {
   void test() throws Exception;
public interface Bar extends Foo {
   void test();
}Now, I find it strange that method test() for interface Bar does not need to define Exception in its throws clause. When I first started with Java I was using Java 1.4.2; I now use Java 1.6. I cannot remember ever reading about this before and I have been unable to find an explanation or tutorial on how (or why) this works.
Consider a more practical example:
Say there is an API that uses RMI and defines interfaces as follwows:
public interface RemoteHelper extends Remote {
   public Object select(int uid) throws RemoteException;
public interface LocalHelper extends RemoteHelper {
   public Object select(int uid);
}As per the RMI spec every method defined in a Remote interface must define RemoteException in its throws clause. The LocalHelper cannot be exported remotely (this will fail at runtime due to select() in LocalHelper not having RemoteException in its clause if I remember correctly).
However, an implementing class for LocalHelper could represent a wrapper class for RemoteHelper, like this:
public class Helper implements LocalHelper {
   private final RemoteHelper helper;
   public Helper(RemoteHelper helper) {
      this.helper = helper;
   public Object select(int id) {
      try {
         return (this.helper.select(id));
      } catch(RemoteException e) {
         // invoke app failure mechanism
}This can uncouple an app from RMI dependancy. In more practical words: consider a webapp that contains two Servlets: a "startup" servlet and an "invocation" servlet. The startup servlet does nothing (always returns Method Not Allowed, default behaviour of HttpServlet), except locate an RMI Registry upon startup and look up some object bound to it. It can then make this object accessible to other classes through whatever means (i.e. a singleton Engine class).
The invocation servlet does nothing upon startup, but simply calls some method on the previously acquired remote object. However, the invocation servlet does not need to know that the object is remote. Therefore, if the startup servlet wraps the remote object in another object (using the idea described before) then the invocation servlet is effectively removed from the RMI dependancy. The wrapper class can invoke some sort of failure mechanism upon the singleton engine (i.e. removing the remote object from memory) and optionally throw some other (optionally checked) exception (i.e. IllegalStateException) to the invocation servlet.
In this way, the invocation servlet is not bound to RMI, there can be a single point where RemoteExceptions are handled and an unchecked exception (i.e. IllegalStateException) can be handled by the Servlet API through an exception error page, displaying a "Service Unavailable" message.
Sorry for all this extensive text; I just typed out some thoughts. In short, my question is how and why can the throws clause change when overwriting a method? It's nothing I need though, except for the clarity (e.g. is this a bad practice to do?) and was more of an observation than a question.
PS: Unless I'm mistaken, this is basically called the "Adapter" or "Bridge" (not sure which one it is) pattern (or a close adaptation to it) right (where one class is written to provide access to another class where the method signature is different)?
Thanks for reading,
Yuthura

Answer 1

Yuthura wrote:
I know it may throw any checked exception, but I'm pretty certain that an interface that extends java.rmi.Remote must include at least java.rmi.RemoteException in its throws clause (unless the spec has changed in Java 1.5/1.6).No.
A method can always throw fewer exceptions than the one it's overriding. RMI has nothing to do with it.
See Deitel & Deilte Advanced Java 2 Platform How To Program, 1st Ed. (ISBN 0-13-089650-1), page 793 (sorry, I couldn't find the RMI spec quick enough). Quote: "Each method in a Remote interface must have a throws clause that indicates that the method can throw RemoteException".Which means that there's always a possibility of RemoteException being thrown. That's a different issue. It's not becusae the parent class can throw RE. Rather, it's because some step that will always be followed is declared to throw RE.
I later also noticed I could not add other checked exceptions, which made sense indeed. Your explanation made perfect sense now that I heard (read) it. But just to humour my curousity, has this always been possible? Yes, Java has always worked that way.
PS: The overwriting/-riding was a grammatical typo (English is not my native language), but I meant to say what you said.No problem. Minor detail. It's a common mistake, but I always try to encourage proper terminology.