Doubt in K&B SCJP 5: topic _OVERRIDING

[raghu dubey]

Hi,

The book clearly states that "The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass'exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares."

However, just going to the next page, it gives an example which works as said in the book, but directly seems to voilate the previous rule as well as the dynamic invocation of methods in a valid override scenario. Personaaly I feel this is a inconsistency or may be a bug in the java language itself. Please suggest.

====================Here is the code================
If a method is overridden but you use a polymorphic (supertype)
reference to refer to the subtype object with the overriding method, the compiler
assumes you�re calling the supertype version of the method. If the supertype version
declares a checked exception, but the overriding subtype method does not, the compiler
still thinks you are calling a method that declares an exception (more in Chapter 5).
Let�s take a look at an example:
class Animal {
public void eat() throws Exception {
// throws an Exception
}
}
class Dog2 extends Animal {
public void eat() { // no Exceptions }
public static void main(String [] args) {
Animal a = new Dog2();
Dog2 d = new Dog2();
d.eat(); // ok
a.eat(); // compiler error -
// unreported exception
}
}
This code will not compile because of the Exception declared on the
Animal eat() method. This happens even though, at runtime, the eat() method used would be the Dog version, which does not declare the exception.
============
thanks.

[ahmed yehia]

The compiler assumes you are calling the super- type version which declares an exception so you need to catch it, although the method to be choosen is of the sub- type version selected dynamically at runtime but the compiler doesnt know that.

[Anonymous]

Hi,

This is just an addition to what Ahmed explained. Overriding has something to do with Runtime scenario. Objects on which methods to be called is determined at Run time in polymorphism. But while compiling , compiler still gives importance to the object reference being used. So for eg., if the method declared in a parent class has throws keyword, and we are using the parent class object reference to invoke that method, even though the actual object being referred is child, even then compiler believes that method is actually being called on parent object rather than child object , since being referred by parent object and gives error , if the exception being thrown is not captured.

To put it simple, rather than beating round the bush , it is rather easy to understand, if we believe that actual object being used is determined at runtime , but compiler checks the parent's signature to be matched.

[Mack Stevens]

Good question.....
See there is no bug as you think in virtual method invocation technique.
When you are writing "a.eat()" in Dog2 class ,it refers to Animal class at Compiletime and Dog2 class at runtime.So your code is generating an exception(as it refers to Animals add() method at compiletime) in the main method and its is not thrown.You have handled the exception in Animal class,but here the exception is generated in main method.
SOLUTION:throw exception in main method

...........................................................................
Regards,
Mack.

[Gitesh Ramchandani]

Originally posted by Mack Stevens:
Good question.....
See there is no bug as you think in virtual method invocation technique.
When you are writing "a.eat()" in Dog2 class ,it refers to Animal class at Compiletime and Dog2 class at runtime.So your code is generating an exception(as it refers to Animals add() method at compiletime) in the main method and its is not thrown.You have handled the exception in Animal class,but here the exception is generated in main method.
SOLUTION:throw exception in main method

...........................................................................
Regards,
Mack.

Dear Mack,

is this the solution which applies to every such case wherein we don't provide a throws clause in the overridden child method.

Regards,
gitesh

[raghu dubey]

Thanks all for the response,

I perfectly agree on the behaviour of the code and explaination. But if this is the scenario, I think we might want to see some modification in the Line

"The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass'exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares."

That is because we just saw a scenario where this statement does not fully hold true.

Not sure if all of you believe that.

Thanks

[Mack Stevens]

Hi...............................
Try this:
class Sample
{
void test() throws Exception
{}
}

class SampleTest extends Sample
{
void test() throws Exception
{}
public static void main(String ar[])
{
Sample s=new Sample();
s.test(); //Exception
Sample t=new SampleTest();
t.test();//Exception
}
}


The above code follows as what I said.
..................................................
Regards,
Mack

[Gitesh Ramchandani]

thanks Mack