Interface and methods and exceptions

[Panda Mima]

I have the following interface:

...
public interface MyIF {
public void methodX() throws RuntimeException();
public void methodY() throws MySpecialException();
}
...

and classes:

...
public class MyFirstImpl implements MyIF {
public void methodX() {
// note that there is no 'throws' in declaration of this method
}
public void methodY() {
// note that there is no 'throws' in declaration of this method
}
}
...

and

...
public class MySecondImpl implements MyIF {
public void methodX() throws RuntimeException() {
...
}
public void methodY() throws MySpecialException() {
...
}
}
...

Everything compiles fine. For me it's not very clear, why interface can declare method which throws some exception, and class can implement this method without throwing exception.

Actually I got that from Business Interface pattern explanation. Where your interface extending EJBObject needs to declare methods which are throwing RemoteException(), but in EJB (Bean) class you implement methods which are not throwing this exception. And in this pattern you create mediator interface with all these methods throwing exception, and extend this interface by your interface (EJBObject' one) and implement this interface by your EJB (Bean). And everything works!

Can somebody clarify me if there some rule about that or else?

Thanks!

[John Kelty]

When implementing a method, or overriding it, your exception clause can leave off any of the exceptions in the Interface or base class version of the method, but your new method may not add any exceptions.

Consider this declaration:

public method(MyIF f) throws MySpecialException {
f.methodY();
}

public void doIt(String args[]) {
MyIF foo = new MyFirstImpl();
MyIF bar = new MySecondImpl();
method(foo);
method(bar);
}

So what should method throw? The only thing it has to go by is the exception clause defined in the MyIF interface, so it has to throw a MySpecialException. By extension, any object that has a compile time type of MyIF must not throw anything except a MySpecialException.

method(foo) is okay because MyFirstImpl() doesn�t throw anything, so the compiler is happy. method(bar) is okay too because mySecondImpl() throws the expected MySpecialException.

If you had a MyThirdImpl that throws an IOException, say, that would not be okay because that would not be expected by method().

Why define an implementation without a throws clause as in MyFirstImpl? You might use the type more specifically, as in:

public methodTwo(MyFirstImpl f) {
f.methodY();
}

public void doIt(String args[]) {
MyIF foo = new MyFirstImpl();
MyFirstImpl bar = new MyFirstImpl();
methodTwo(foo);
methodTwo(bar);
}

Now you�ve been able to define a public method without a throws clause, which certainly makes the public API easier to use and friendly than one that throws an exception when it doesn�t really need to... If users of your API know they have a MyFirstImpl instead of just a MyIF, then they don�t have to even worry about MySpecialException.

[Stan James]

The interface warns anyone who will call methodY on an implementing object that it's possible the method will throw MySpecialException. The compiler requires the caller to be prepared to handle it or let it bubble up. But nothing requires an implementation to actually throw one.\

Here's a typical caller:

public void doSomething( MyIF arg )
{
   try
   {
      arg.methodY();
   }
   catch( MySpecialException )
   {
      eek!
   }
}

As John pointed out, the compiler won't allow an implementing class to throw some new exception, like MyOtherCustomException, because the interface did not properly warn the caller that they have to handle it. The compiler won't let new classes surprise the callers. We should all be very glad of that!

I think where John wrote

method(foo)

he really meant

foo.methodY()

Does that sound right?

[John Kelty]

Good elaboration.

I had meant mean method(foo), with the intent that doIt() calls method(foo) which calls f.methodY(), but looking back, I could�ve in fact had doIt call foo.methodY() directly and simplified the example.

[Stan James]