This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Doubt regarding signature of overridden methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Doubt regarding signature of overridden methods" Watch "Doubt regarding signature of overridden methods" New topic
Author

Doubt regarding signature of overridden methods

Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

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?


~ Mansukh
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37907
    
  22
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

Joined: Jul 27, 2010
Posts: 1157

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
Sheriff

Joined: Oct 13, 2005
Posts: 37907
    
  22
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

Joined: Jul 27, 2010
Posts: 1157

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.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2229
    
    7

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.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

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
Sheriff

Joined: Oct 13, 2005
Posts: 37907
    
  22
The characteristic predicates are at a much more fundamental level than principles of OO.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

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
Sheriff

Joined: Oct 13, 2005
Posts: 37907
    
  22
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

Joined: Jul 27, 2010
Posts: 1157

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Doubt regarding signature of overridden methods
 
Similar Threads
Overriding a Static Function
Exception and Overriding
Exceptions in Overriding methods??
Broader exceptions thrown by methods that implement interfaces
Static Methods