• 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

Method overriding in Exceptions

 
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!!!
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 10
Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79151
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Marshal
Posts: 79151
377
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Master Rancher
Posts: 4796
72
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Mike and Ritche for your views. I will go through the link provided by you.
Cheers!!!
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
At least Mike and I agreed about RuntimeException being a bad name
I didn't know about Spring throwing uncheckced exceptions.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Campbell, Mike, Winston.
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome. Even if I did get it wrong.
 
reply
    Bookmark Topic Watch Topic
  • New Topic