• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Method Overriding Rules

 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First tell us what you think.
 
Vaibhav G Garg
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 80866
505
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic