aspose file tools*
The moose likes Beginning Java and the fly likes Method overriding in Exceptions 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 in Exceptions" Watch "Method overriding in Exceptions" New topic
Author

Method overriding in Exceptions

Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 175
Hello Everyone
Please help me to understand the following questions :

Que 1 Why is it that, If the superclass method does not declare an exception, subclass overridden method cannot declare the checked exception but it can declare unchecked exception ?

Que2 Why is it that, If the superclass method declares an exception, subclass overridden method can declare same, subclass exception or no exception but cannot declare parent exception ?

Thanks!!!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38340
    
  23
Tarun Oohri wrote: . . . Que 1 Why is it that, If the superclass method does not declare an exception, subclass overridden method cannot declare the checked exception but it can declare unchecked exception ?
That is quite incorrect. You cannot declare a new Exception without violating the Liskov substitution Principle. If the superclass' method is feasible without Exceptions then the subclass' method must be feasible without Exceptions.

What you mean is, if you throw a new RuntimeException, the compiler will not notice. That is something quite different.
Que2 Why is it that, If the superclass method declares an exception, subclass overridden method can declare same, subclass exception or no exception but cannot declare parent exception ?

Thanks!!!
It is actually the same reason. If you catch a particular kind of Exception, you catch its subclasses. Not its superclass.
Wilhelm Vogt
Greenhorn

Joined: Jul 11, 2012
Posts: 10

You cannot declare a new Exception without violating the Liskov substitution Principle. If the superclass' method is feasible without Exceptions then the subclass' method must be feasible without Exceptions.

I agree that throwing additional Exceptions will violate the Liskov substitution Principle. However, as unchecked Exceptions might be thrown without declaring them, the compiler allows declaring (and throwing) them in overriding methods - for the compiler, the overridden method is allowed to throw an unchecked exception, so the overriding method is allowed to declare them. According to the JLS: 11.2. Compile-Time Checking of Exceptions
The unchecked exception classes (ยง11.1.1) are exempted from compile-time checking.

Also the following code compiles fine in eclipse

Regards Wilhelm
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38340
    
  23
What I meant is that there is a big difference between code which compiles and correct code. Your example shows the compiler not noticing.
If that overriding method actually throws a NullPointerException (NPE) which the superclass' method doesn't, then it is incorrect code. If the superclass' method might throw a RuntimeException, then it is correct code.

Another consideration: unchecked Exceptions are less predictable than checked. You cannot tell whether that code is going to throw an NPE. It would be pointless to catch it anyway.
Not got enough time to give a longer answer now. Sorry.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 175


Thanks C.Ritchie and W.Vogt for sharing your lightening knowledge.
One more thing i would like to know :
Is it correct to say :
Checked Exceptions are compile time exceptions such as Exception , IOException , SQLException etc
UnChecked Exceptions are Run time Exceptions such as RunTimeException , Error etc
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38340
    
  23
Tarun Oohri wrote: . . .
Is it correct to say :
Checked Exceptions are compile time exceptions such as Exception , IOException , SQLException etc
UnChecked Exceptions are Run time Exceptions such as RunTimeException , Error etc
No. There is no such thing as a compile‑time Exception. The name RuntimeException is confusing. It does not mean an Exception which occurs at runtime, but an Exception which occurs (entirely) inside the runtime. Other Exceptions occur partially outwith the runtime. At least that is the theory.
If you get a runtime exception (eg NullPointerException, divide by zero) you will have to go back to the code and ensure the null is replaced by a real reference or the 0 by a different number. There are very few runtime exceptions which can be sorted out without altering the code. So there is no point in catching them.
A checked Exception is something which happens partially outwith the runtime and can be sorted out. At least that is the theory. IOException because network cable unplugged: reconnect cable. FileNotFoundException: try a different file. SQLException because of incorrect text passed: try different SQL text. The compiler forces the programmer to handle checked Exceptions because it may be possible to recover from them and continue running the application.

I presume you have read the Java Tutorials section about Exceptions?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3007
    
    9
Campbell Ritchie wrote:The name RuntimeException is confusing. It does not mean an Exception which occurs at runtime, but an Exception which occurs (entirely) inside the runtime. Other Exceptions occur partially outwith the runtime. At least that is the theory.

Hmmm, that makes no sense to me. All Exceptions, all Throwables really, are entirely run-time phenomena. A RuntimeException is in no way more associated with the runtime than any other exception. I think it's better to say that RuntimeException is an entirely stupid and misleading name - it should have been UncheckedException. Because that's what it is.

Campbell Ritchie wrote:If you get a runtime exception (eg NullPointerException, divide by zero) you will have to go back to the code and ensure the null is replaced by a real reference or the 0 by a different number. There are very few runtime exceptions which can be sorted out without altering the code. So there is no point in catching them.

This is extremely arguable, and advice like this often leads to irresponsible code. It can be entirely acceptable to catch runtime exceptions for the purpose of LOGGING THEM, along with logging any contextual data about what was going on when the exception occurred.

Additionally, there are many folks using unchecked exceptions for things that are not necessarily programmer errors. If you use Spring or Hibernate, you get a lot of specialized RuntimeExceptions for things that might have been checked exceptions if they were part of the standard Java libraries. Because different people have different philosophies about what checked exceptions are good for. Catching runtime exceptions can be perfectly acceptable in some circumstances, and programmers who are afraid to do it because they've been told it's bad often end up failing to properly log failures, or recover from them.
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 175
Thanks Mike and Ritche for your views. I will go through the link provided by you.
Cheers!!!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38340
    
  23
At least Mike and I agreed about RuntimeException being a bad name
I didn't know about Spring throwing uncheckced exceptions.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7639
    
  19

Campbell Ritchie wrote:At least Mike and I agreed about RuntimeException being a bad name

And I'm going to wade in here, because personally I think it's a perfectly reasonable name, because it's an Exception that you can expect to see at runtime.

Regardless of the merits of the decision, Java is one of the few languages that makes this distinction; and the mechanics of checked Exceptions are that they must be declared or caught, so unless your main() method declares a checked Exception, you WONT see it at runtime.

My 2¢.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1011
    
  15
Thank you Campbell, Mike, Winston.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38340
    
  23
You're welcome. Even if I did get it wrong.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Method overriding in Exceptions