Exceptions and overriding

[Serghei Jelauc]

Hi javers.
I have found that question:

Which statements regarding the following code are correct ?
class Base
{
   // NullPointerException is a subclass of RunTimeException.
   // IOException is a not subclass of RunTimeException.
   void method1() throws java.io.IOException, NullPointerException
   {
      someMethod("arguments");
      // some I/O operations
   }
   int someMethod(String str)
   {
      if(str == null) throw new NullPointerException();
      else return str.length();
   }
}
public class NewBase extends Base 
{
      void method1() 
      {
           someMethod("args");
      }
}

and the answer is "method1 in class NewBase does not need to specify any exceptions", but as I know the overriding method must not thow new or broader checked exception that were declared by the overriden method, but at least it have to declare (or throw) the same exception or it's subclass?
So in the above code we have to declare at least IOException or it's subclass, haven't it?
Thanks in advance.

[Corey McGlone]

If you check out the JLS, §8.4.4 Method Throws, you'll see this:

A method that overrides or hides another method (�8.4.6), including methods that implement abstract methods defined in interfaces, may not be declared to throw more checked exceptions than the overridden or hidden method.
More precisely, suppose that B is a class or interface, and A is a superclass or superinterface of B, and a method declaration n in B overrides or hides a method declaration m in A. If n has a throws clause that mentions any checked exception types, then m must have a throws clause, and for every checked exception type listed in the throws clause of n, that same exception class or one of its superclasses must occur in the throws clause of m; otherwise, a compile-time error occurs.

To break that down, an overriding method can throw any subset of checked exceptions declared by the overridden method. That subset can include the entire set (meaning that the overriding method can throw all of the exceptions the overridden method can throw) and it can also include the empty set (meaning that the overriding method throws no expceptions whatsoever).
The key is that the overriding method can not throw a checked exception that the overridden method does not declare.
I hope that helps,
Corey

[Sumitro Palit]

Lets look at a reason behind this design:

//1. 
Base b1 = new Base();
try{
   b1.method1(); 
}
catch( IOException e){
   // will come here if method1 actually throws  an IOException
}
//2. 
Base b2 = new NewBase();
try{
   b2.method1(); 
}
catch( IOException e){
   // At runtime,
   // method1 won't throw IOException in this case, 
   // but the try-catch block wont harm.
   // If method1 threw a sublass of IOException, it would
   // get caught here => narrower exceptions might be thrown 
   // by the overriding method in a subclass.
}
//3.
// assume method1 in NewBase throws a new exception, MyException
Base b2 = new NewBase();
try{
   b2.method1(); 
}
// method1 might throw MyException, 
// but based on the reference b2 (Base ref),
// we are not aware of it at compile time,
// so we dont handle it - bad for dynamic
// decision making. MyException will slip through
// our check (and might cause havoc.) 
// We dont want to hardcode exception handling by 
// manually inspecting each overriding method for 
// additional exceptions and add catch clauses for 
// each new or broader exception.
catch( IOException e){
   
}

In case 1, the compiler knows that method1 might throw IOException
In case 2, at runtime method1 (the overriding version in NewBase) doesn't throw IOException, however at compile time the decision has to be made based on the reference type, ie Base's method1 signature.
So, if the runtime class is a subclass of the parent, and the subclass's overriding method was allowed to throw newer or broader exceptions then common exception handling based on the parent reference's method signature would not be possible. Case 3 illustrates this scenario.
The crucial point is that using a base class reference and providing the runtime via any subclass is a powerful paradigm and would break if this exception handling rule wasn't enforced.
- ortimuS
[ April 06, 2004: Message edited by: ortimus tilap ]