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

overriding in java

Suresh KumarPandey
Ranch Hand

Joined: Sep 08, 2012
Posts: 46



Why the foo method of class X is not throwing a a compile error because according to the override rule ,if the superclass method has not declared exception ,the subclass method can't declare a new exception
Ivan Jozsef Balazs
Rancher

Joined: May 22, 2012
Posts: 968
    
    5
RuntimeException is not a checked one.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14719
    
  25

And that rule is only valid for checked exceptions.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Shaddy Khan
Greenhorn

Joined: Jul 26, 2013
Posts: 5

@Suresh let me correct your concept of overriding method in case of throw clause: An overriding method can throw All, None, Subset or subclass exceptions of the exceptions declared in throws class of overridden method in case of checked exceptions. Compiler validates this rule in case of checked exception only not in case of unchecked exceptions defined in throws clause.
Now consider your code you have defined unchecked exception in your overriding method's throws clause. so compiler will not gives any error in this case.
Note: java.lang.RuntimeException , java.lang.Error and their subclass comes under checked exceptions.

Hope it clears your doubt.
Do let me know if anything remains unclear.
Keep coding

Sreevatsa Turuvekere Laxmi Narayana
Greenhorn

Joined: Feb 26, 2015
Posts: 10

>>An overriding method can throw all, none, subset or subclass exceptions of the exceptions declared in throws class of overridden method, in case of checked exceptions. Compiler validates this rule in case of "checked exception only" and not in case of unchecked exceptions defined in throws clause.

That was helpful. Actually I too had same doubt as Suresh with the following code snippet:







S Majumder
Ranch Hand

Joined: Jun 03, 2009
Posts: 346
Please share your doubts ...

Satya
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14719
    
  25

Welcome to the Ranch.

So, do you still have a question, or was it already answered?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 41986
    
  31
Welcome to the Ranch
Since the thread is about 1½ years old, there is a possibility that you won't get a response from the original poster.
I have added code tags, which you should always use, to your post. Doesn't it look better!
Don't use com.test as a package name since that domain is already in use. Look here for package names. In fact on the beginning forum you might do well to omit the package names since some people wouldn't know how to compile the code in packages.
Please tell us where the quote at the beginning of your post comes from.

The idea of inheritance is that a subclass IS‑A superclass and a subclass object IS‑A superclass object. And the Liskov Substitution Principle (=LSP) says that every subclass method must be called as one would call a superclass method without any surprising behaviour. So, if you have a method which does not throw an Exception then you will be very displeased to use its overridden version in a subclass and suffer an Exception. Example:- In Object#equals it says
The API's 4th & 5th bullet points wrote:for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
For any non-null reference value x, x.equals(null) should return false.
Now, you know a method without void return type must return something and the only way it can get out of returning something is to throw an Exception. If it always returns something, that does not allow for Exceptions. That means that equals() methods are not permitted to throw Exceptions. Now what about this sort of implementation of equals:-That is an incorrect implementation because it will throw a null pointer exception if you pass a null reference. There is no problem about getClass() because I marked the class final.

What you are saying with throws CloneNotSupportedException is that your method might throw it. The compiler notices because it is a checked Exception. Even though the method does not actually throw it, an overriding might. So it passes. When you get to the subclass methods, they have incorrect declarations because they are not subtypes nor a subset of the superclass' declarations. Throwing those Exceptions might breach the LSP, but the compiler ignores them because they are unchecked type.

Unchecked Exceptions are unchecked because you usually have to correct the code to prevent the Exception, and Errors are unchecked because they are usually not possible to recover from. AssertionError should be a runtime exception, but when assert was added in J2SE1.4 they thought it should be an Error so as not to be caught by catch (Exception ex) statements. As well as that, it is often difficult to predict when an unchecked Exception occurs (look at null pointer exceptions), so they thought it best not to check for them.

You can get away with unchecked Exceptions in overridings not because they are permissible but because the compiler ignores them. There is a lot about Exceptions in the Java Tutorials.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 41986
    
  31
A few minutes ago, I wrote: . . . they thought it should be an Error . . .
And you can find even stranger design in this class.
Sreevatsa Turuvekere Laxmi Narayana
Greenhorn

Joined: Feb 26, 2015
Posts: 10

Thank you, S Majumdar, Jesper de Jong and Campbell.
@Campbell: Thank you for that wonderful response.

A few days ago, one of my colleagues asked a question which read something like:

Suppose a superclass method declared as "int returnNum() throws CloneNotSupportedException" is overriden in subclasses.
Which of the following overriding declarations in subclasses are improper?
  • int returnNum() throws RuntimeException
  • int returnNum() throws AssertionError
  • int returnNum()
  • int returnNum() throws Exception


  • All that I knew then about method overriding was:
  • The overriding subclass method must have the same signature (name, plus the number and the type of its parameters) and return type, as the superclass method.
  • The overriding subclass method must have the same or broader access specifier, as the superclass method.
  • The exception thrown by overriding subclass method must be same, narrower, as the superclass method or may not throw an exception at all.

  • "All are incorrect, except the third option.", was my immediate reply to her.
    But, when compiled and ran the code snippet from my previous post, the first three options comiled fine except for the last option!
    RuntimeException(unchecked) is a subclass of Exception and a sibling to CloneNotSupportedException(checked).
    AssertionError(unchecked) is a subclass of Error(unchecked).
    I was confused because these exceptions and errors were not in superclass-subclass relationship. Also, unchecked and checked exceptions were mixed in options.
    Here, in superclass method, the exception being thrown is CloneNotSupportedException(checked). So, Shaddy Khan's earlier post cleared the mist.
    Shaddy Khan wrote:An overriding method can throw all, none, subset or subclass exceptions of the exceptions declared in throws class of overridden method, in case of checked exceptions. Compiler validates this rule in case of "checked exception only" and not in case of unchecked exceptions defined in throws clause.

    So, my questions are:
  • Should we first consider whether the exception thrown in superclass is checked or unchecked and then apply the proper rule?
  • What is the correct answer for the above question?
  • Can options 1 and 2 be considered as overloading instead as overriding?

  • Kindly clarify.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 41986
        
      31
    You are correct that all but the third are improper declarations because they breach the LSP.
    Only the one with throws Exception will fail to compile because the compiler doesn't check those other types of exception.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 41986
        
      31
    Sreevatsa Turuvekere Laxmi Narayana wrote: . . .
  • Can options 1 and 2 be considered as overloading instead as overriding?

  • . . .
    No. They have the same signature and are therefore not overloaded.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: overriding in java