Exception doubt

[Girish Nagaraj]

class MyException extends Exception {}

abstract class A {

abstract void check() throws MyException;
}

class B extends A {

void check() {

System.out.println("In method()");
}
}

public class Test {

public static void main(String[] args) {

B b = new B();
System.out.println("Working");
}
}

----------------------***-------------------

What are Inheritence rules with respect to Exceptions?

class B extends class A and overriden method check in B doesn't throw MyException (Compilation is successful), It has to right?

Any please list the basic inheritence rules...

[Sanjeev Singh]

The basic rule is the overrided method should not throw any exception which is broader than the overriden method.In other words the invoking a method,either overriden or overrided, on the super class reference should not throws any exception which is not known to the superclass.

Can some one can give the pros and cons for the same?

[Joe San]

Hi Sanjeev,

You are right. At the same time if an Overridden method in the superclass throws an exception, it is necessary that the method in the subclass also throws that exception or probably narrower one.

[Sanjeev Singh]

Jothi,
I find one benefit of this rule(rules are made for change ) is that if you have the refernce of the super class to invoke the overriden method and suddenly you subclassed it to change its behavior,then you are very free not to declare any extra catch block in your previous codes.

public class Test {
public static void main(String[] args) {
try{
A a = new A();//cosidering that A is non-abstract
a = new B();//subclass reference 
}catch(MyException me){}//no need to add extra catch blocks  :)  
System.out.println("Working");
}
}

[Burkhard Hassel]

Hi ranchers,

what Sanjeev wrote means for example, that your check() method in class B cannot throw an exception of the class Exception itself. Only exception of type MyException (including subclasses).

And it means also, that it is possible to throw no exception at all!

So it not necessary that the subclass throws a MyException, and the code provided from Girish compiles happily.


Idea: (pros and cons)

The superclass (A) method may throw a MyException, which is a checked exception (i.e. no RuntimeException), so it declares it.
But in a subclass, the programmer may have made such a good job, that no MyException can occur any longer and so (s)he does not have to declare it. Or (s)he may - not in this example - made the code good enough not to throw a MyException but a subclass of it.

The rule not to throw superclasses of checked Exceptions makes sense in a way to force the programmer to make the methods robust enough NOT to make "more exceptions than its ancestor".
Less or no "mistakes" are fine, more (bigger) won't compile.

That's how I understand this.



Having the method signature of an abstract method throwing a checked exception in my opinion makes sense only in a sense of warning. To inform the programmer that implementations of that method in the first concrete subclass (class B) may also throw the MyException. And so they'd better declare it. Also if it is not required for the code to compile.
Just to inform people who extend class B this via API and compile/not compile about the possibility of such an exception.


Girish Nagaraj posted November 05, 2006 05:01 AM

Any please list the basic inheritence rules...

I guess, you mean the rules for overriding.


Not a list, but the chapter about overriding in the language specification:
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8


But I am trying to make a list:

Overriding:
Overridden methods must have
1) same method name (or identifier, how they call it).
2) same return type - OR type of a subclass, called covariant return, Java 5 only!.
3) same parameter list (otherwise it's overloading)
4) same or wider access level
remark: protected - don't get confused by the name, protected has a wider access level than default.
5) checked exceptions: the same or "smaller" (meaning subclasses) or even zero checked exceptions compared to the super class. No wider checked Exceptions!
6) unchecked exceptions (i.e. subclasses of RuntimeException): don't follow rule #4.
7) final and private methods cannot be overridden. Private methods can be redefined, that's no override.
8) static methods aren't overridden, but hidden. But these also follow rules 1-7 and 10-12. If you correctly hide a static method, the @Override annotation will cause no compile time error.
9) you cannot have a non-static method in a subclass with the same name, identifier and parameter list as a static method in the superclass. And the other way round, you cannot have a static method in a subclass with the same name, identifier and parameter list as a non-static method in the superclass.
10) The annotation
@Override
forces the compiler to check if the following methods really overrides a method from the superclass. If not (e.g. typo in the method's name) it will not compile (Java 5 only).
11) Generics: I don't know if the following is on the exam, but:
parameters and return types must have the same generic type in an overridden method. E.g. the following will not compile:

import java.util.*:
class SuperClass {
void foo(List<SuperClass> list){
}
}
class SubClass extends SuperClass {
void foo(List<SubClass> list){
}
}

In spite of the fact that the erasure type of the parameter "list" is the same, it is not a legal override. And because the erasure type is the same it also cannot be an overload.
The errors will be "Name clash" for parameters, "incompatible return types" for return types.
11) There are special rules for overriding hashCode and equals. Try to find something somewhere else about that. These rules don't say anything about legal, but appropriate overrides.
12) Methods that are strictfp or synchronized don't have to be so in an overridden method. They can, but it's not required.
13) You have polymorphism with overridden methods. Not with overloaded ones. And not with variable, but that's a different topic.


Rule #13 is most important



Yours,
Bu.

[Joe San]

Hi Bu,

Thanks for the lengthy explanation. There is a list for Overriding in the K&B book.