• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Doubt regarding signature of overridden methods

 
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

Consider the following scenario:




If the sub class method m1 which is overriding the super class m1 method is throwing say a ClassNotFoundException exception, obviously we need to either say throws in its signature or handle it using try catch protocol. But then if we go for the option of changing the method signature of sub class overriding method, it will no longer be method overriding. Correct? How do I tackle this issue? If I have 100 places where this super class A method m1 is being overridden in sub class(es), and if say 60 of those throw some checked exception, then what options do I have ? Obviously we cannot change the signature of method as then we cannot override it. So the only option is to handle the exception(s) at 60 different places is it? Then why at all have the option of having a throws clause when ultimately we can(rather are forced) to go at a more finer level and enclose the code that could throw a checked exception?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That has nothing to do with signatures. That has to do with trying to load a non‑existent class. I think a throws clause is not actually part of the signature. You would have to check override‑equivalence in the java Language Specification.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:That has nothing to do with signatures. That has to do with trying to load a non‑existent class. I think a throws clause is not actually part of the signature. You would have to check override‑equivalence in the java Language Specification.



Correct Ritchie. The only things that need to be exactly the same are name, return type(can be a sub type of the super class, covariant), access modifier(can't be more restrictive). Whether the overridden method code throws some unchecked exception or not is a separate issue. throws clause is not a part of method signature. One thing that we do need to make sure is that if the super-class method declares checked exception say X, then the code in subclass overriding method should not throw broader exceptions than X. It can however throw exception X and narrower exceptions. Correct?
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you mean what does the JLS say, or what is the right way to override methods?
The JLS will tell you that it is a compile‑time error for an overriding method to specify a checked exception unless it is a subtype of an Exception specified by the overridden method.
The correct way to override a method is not to specify or throw any Exceptions which are not thrown by the overridden method. That means the methods like equals() and toString() which do not throw any Exceptions when invoked on an instance of java.lang.Object, should never throw Exceptions of any sort in subtypes. The reason is to do with the Liskov Substitution Principle. If a method of a subtype throws a “new” Exception, then the subtype is not behaving as the supertype object would. Or, using Abrial’s characteristic predicates, ∀ m • fis(msupertype) ⇒ fis(msbrtype).
But the compiler only looks for checked Exceptions. The fact that the compiler will not notice a toString() method like this does not mean it is right:-
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Do you mean what does the JLS say, or what is the right way to override methods?
The JLS will tell you that it is a compile‑time error for an overriding method to specify a checked exception unless it is a subtype of an Exception specified by the overridden method.
The correct way to override a method is not to specify or throw any Exceptions which are not thrown by the overridden method. That means the methods like equals() and toString() which do not throw any Exceptions when invoked on an instance of java.lang.Object, should never throw Exceptions of any sort in subtypes. The reason is to do with the Liskov Substitution Principle. If a method of a subtype throws a “new” Exception, then the subtype is not behaving as the supertype object would. Or, using Abrial’s characteristic predicates, ∀ m • fis(msupertype) ⇒ fis(msbrtype).
But the compiler only looks for checked Exceptions. The fact that the compiler will not notice a toString() method like this does not mean it is right:-



I was reading the Kathy - Bert book and I wrote what I read about correct way of overriding a method is. I did not read through the JLS. Now you have put me in another fix. What are these "Liskov Substitution" principle and Abrial characteristic predicates. Could you perhaps provide some link where I can educate myself regarding these, now that we have dived into the reasons.
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mansukhdeep Thind wrote:
What are these "Liskov Substitution" principle and Abrial characteristic predicates. Could you perhaps provide some link where I can educate myself regarding these, now that we have dived into the reasons.



There are a few OO design principles which can be found here.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

K. Tsang wrote:

Mansukhdeep Thind wrote:
What are these "Liskov Substitution" principle and Abrial characteristic predicates. Could you perhaps provide some link where I can educate myself regarding these, now that we have dived into the reasons.



There are a few OO design principles which can be found here.



Thank you. I shall go through the literature provided.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The characteristic predicates are at a much more fundamental level than principles of OO.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:The characteristic predicates are at a much more fundamental level than principles of OO.



Are you suggesting that I keep these tasks on hold for now as it would be too much in one go?
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Learn about the Liskov Substitution Principle now. Leave characteristic predicates until you know some generalised substitution language. Which is an entirely theoretical language used to reasoning about programs, not for creating programs.
The little predicate I wrote means that in all cases where the superclass method will run, the subclass method will run, too.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Learn about the Liskov Substitution Principle now. Leave characteristic predicates until you know some generalised substitution language. Which is an entirely theoretical language used to reasoning about programs, not for creating programs.
The little predicate I wrote means that in all cases where the superclass method will run, the subclass method will run, too.



OK.
 
I didn't do it. You can't prove it. Nobody saw me. The sheep are lying! This tiny ad is my witness!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic