Method Overriding Rules

[Vaibhav G Garg]

Hi All,

Method Overriding follows the rules given below:

i. We can not restrict the method access i.e from public to private/protected or from protected to private. Why it is so?

ii. We can't have return type other than the same return type or subclass of the return type defined in the superclass. Why it is so?

iii. We can add more exceptions in the subclass. I am wondering why we can add more exceptions in throws clause in the subclass which were not defined in the superclass?

Please explain these 3 rules and their validation in terms of Method Overriding.

Thanks,
Vaibhav

[Jeff Verdegan]

First tell us what you think.

[Vaibhav G Garg]

Jeff Verdegan wrote:First tell us what you think.

i. We can not restrict the method access i.e from public to private/protected or from protected to private. Why it is so?
<Vaibhav> : I think as we can have a super class variable reference which can refer to a subclass object. So, to achieve this we can't restrict the access since whatever method is visible in superclass, it should not be hidden in subclass.

ii. We can't have return type other than the same return type or subclass of the return type defined in the superclass. Why it is so?
<Vaibhav> : Same as given above. Whatever return type we are expecting for a super class method, similar hierarchy must be followed by subclass.

iii. We can add more exceptions in the subclass. I am wondering why we can add more exceptions in throws clause in the subclass which were not defined in the superclass?
<Vaibhav> : If above two points are correct, then, I wonder why it is different in case of exceptions i.e. if super class doesn't declare any exception then how can we add exceptions in subclasses. We will be having a super class variable referring to a subclass object then how will it handle additional exceptions?

[Jeff Verdegan]

Vaibhav G Garg wrote:

Jeff Verdegan wrote:First tell us what you think.

i. We can not restrict the method access i.e from public to private/protected or from protected to private. Why it is so?
<Vaibhav> : I think as we can have a super class variable reference which can refer to a subclass object. So, to achieve this we can't restrict the access since whatever method is visible in superclass, it should not be hidden in subclass.

Correct. That method declaration is a contract. If we class Parent, then everything that IS-A Parent must honor that contract. If we have Child extends Parent, then a Child IS-A Parent, so it must honor Parent's contract.

ii. We can't have return type other than the same return type or subclass of the return type defined in the superclass. Why it is so?
<Vaibhav> : Same as given above. Whatever return type we are expecting for a super class method, similar hierarchy must be followed by subclass.

Correct and if Parent returns, for example Collection, then Child must also return something that IS-A Collection. Since, for example, ArrayList IS-A Collection, Child can return ArrayList and still honor Parent's contract.

iii. We can add more exceptions in the subclass. I am wondering why we can add more exceptions in throws clause in the subclass which were not defined in the superclass?
<Vaibhav> : If above two points are correct, then, I wonder why it is different in case of exceptions i.e. if super class doesn't declare any exception then how can we add exceptions in subclasses. We will be having a super class variable referring to a subclass object then how will it handle additional exceptions?

Maybe you should write some code that tests your assumption about adding exceptions, and what exceptions we can add. While you're doing so, and trying to understand what's going on, keep in ming that just like with the above points, Child must honor Parent's contract.

[Vaibhav G Garg]

Thanks Jeff! I got it. I was doing a mistake as I was putting different RuntimeExceptions or its subclasses which anyways compile won't complain about.

[Campbell Ritchie]

I beleive that an overriding method should never be able to throw an Exception which is not a subclass of an Exception thrown by its overridden version. The reason is the same as why you can't override a public method with protected access. The method should be accessible and executable under all circumstances under which the superclass' version is executable. So the compiler will complain bitterly if you try something like this, and quite rightly:-

public class Foo
{
   ...
   public void foo()
   {
      ...
   }
   ...
}

class Bar extends Foo//public access to class not essential
{
   ...
   public void foo() throws IOException
   {
      ...
   }
   ...
}

The reason is that you have told the compiler that the Foo#foo method is executable under all circumstances and the Bar#foo method is only executable when no IOException occurs.

But what about this?

public class Foo
{
   ...
   /**
    *blahblahblah
    *@param i blahblahblah
    */
   public void foo(int i)
   {
      ...
   }
   ...
}

public class Bar extends Foo
{
   ...
   /**
    *blahblahblah
    *@param i rhubarbrhubarbrhubarb must not be negative
    *@throws IllegalArgumentException if i < 0
    */
   public void foo(int i)
   {
      ...
   }
   ...
}

The compiler know nothing about this because the compiler ignores IllegalArgumentException (=IAE) and other unchecked Exceptions. After all, you can make mistakes and unchecked Exceptions can occur when you don't expect them. But you have told the user of the method that Foo#foo works under all circumstances, and Bar#foo is not executable for negative arguments. You can get this sort of thing:-

int i = myScanner.nextInt(); //enter -999
Foo f = new Foo();
f.foo(i); // works nicely
f = new Bar();
f.foo(i); //Ouch! Suffers IAE. Breaches Liskov Substitution Principal (=LSP)

The LSP would tell you that a subclass' method must do whatever the superclass' method would do, without any surprises. So even if you say a Bar “IS A” Foo, you cannot really say that a Bar instance “IS A” Foo instance.

This will, I hope, show that throwing “new” Exceptions, even if they are unchecked, is poor design and breaches the principals of inheritance. What follows is legitimate, however.

public class Foo
{
   ...
   public void foo() throws Exception
   {
      ...
   }
   ...
}

public class Bar extends Foo
{
   ...
   public void foo() throws IOException
   {
      ...
   }
   ...
}

Because any user of the Foo#foo method must handle any sort of Exception, they must handle an IOException, so you are not declaring a “new” Exception. You can see a few examples of such practice inthe API: this method declares plain simple Exception so its implementing classes can declare any other type of Exception, or even no Exception at all. That may be the one instance when it is good practice to declare throws Exception, rather than a more specific type of Exception.

[Jeff Verdegan]

Campbell Ritchie wrote:I beleive that an overriding method should never be able to throw an Exception which is not a subclass of an Exception thrown by its overridden version. The reason is the same as why you can't override a public method with protected access.

Yup. Exactly. If the parent declares throws IOException, that means it's promising not to throw anything outside of IOException, and the child must honor that. It can throw any subclass of IOException, because a subclass of IOException IS-AN IOException, and so the parent's contract is still upheld.