Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception Handling in overridden subclass methods

 
Thomas Markel
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
this shows three programms where the subclass – test() method overrides the superclass – test() method without throwing the exception of the superclass test() method.
In Question20 the main() method creates a Question20Sub instance and invokes the overridden test() method which doesn’t throw the IOException. Therefore the compiler complains correctly about it. This is clear for me.
But I cannot understand Question20a and Question20b.
In Question20a I create a mixture object “Question20a myref = new Question20aSub();” As object type still is Question20aSub it invokes the overridden test() method in Question20aSub just as Question20 does – but the compiler doesn’t complain that there is no IOException thrown like in Question20. – Why?
In Question20b it becomes much stranger.
Question20b is nearly the same code as Question20 is but instead of throwing an IOException it throws only an Exception. But instead of Question20 the code in Question20b compiles because it is an Exception instead of an IOException caught in main() method. – WHY?


Result:
D:\JAVA\EigeneProgramme>javac Question20.java
Question20.java:7: exception java.io.IOException is never thrown in body of corresponding try statement
}catch(IOException e){}


Compiles fine and runs with result: In Question20aSub

Compiles fine and runs with result: In Question20bSub
 
boyet silverio
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anybody out there?
Let me see if I understand what you are asking.
My 2 cents on why Question20A works lies in the statement
Question20a myref = new Question20aSub();
Although the initialization class of myRef is Question20aSub, the interpreter still sees "traces" (e.g. throwing of IOException in the overridden method) of Question20A, being the REFERENCE TYPE of myref.
Regarding that of Question20b (typo? there at class name), the code works because the argument in the catch clause, in this case "Exception", is a superclass of IOException. This format gives the catch clause the ability to catch a wider range of exceptions, not only IOException but other sub classes of Exception.
Similarly, if you change the catch argument in Question20 to a superclass of IOException such as Exception or Throwable, it will also work.
By the way, using "try{}catch(Exception e){}" or "try{}catch(Throwable t){}" which are too general works even if the methods (called inside the try{} clause) when created were not declared to throw exceptions.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic