aspose file tools*
The moose likes Beginning Java and the fly likes Method Overriding Rules Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Method Overriding Rules" Watch "Method Overriding Rules" New topic
Author

Method Overriding Rules

Vaibhav G Garg
Ranch Hand

Joined: Sep 23, 2011
Posts: 140
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

First tell us what you think.
Vaibhav G Garg
Ranch Hand

Joined: Sep 23, 2011
Posts: 140
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Sep 23, 2011
Posts: 140
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
Sheriff

Joined: Oct 13, 2005
Posts: 38793
    
  23
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:-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?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:-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.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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Method Overriding Rules