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.