This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

defining exceptions in superclass/subclass - OCA book page 320

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, I hope you are doing well. With my last chapter of the OCA book, Exceptions, I was having some questions and these are the last ones.

I can't entirely understand the explanation about why it's not possible to throw an exception in a subclass method if previously it's not declare in the method from superclass. I mean, I don't understand the meaning of this (although i already memorized it)

Code:
class CanNotHopeException extends Exception{}

class Hopper{
 public void hop(){}
}

class Bunny extends Hopper{
public void hop() throws  CanNotHopeException
}

Literally the book says: Imagine what would happen if subclasses could add checked exceptions - you could write code that calls Hopper's hop() method and not handle any exceptions. Then if Bunny was used in its place, the code wouldn't know to handle or declare CanNotHopException.

This is very confused for me. When it says "you could write code that calls Hopper's hop() method and not handle any exceptions" Does it refer to call through "super.hop"?. And if it is right, from where? maybe from within hop() method from the subclass?  

And at the end of the sentence when it says "Then if Bunny was used in its place, the code wouldn't know to handle or declare CanNotHopException". I don't understand why. Because if I specify how to handle it, I image that there should not be any problem. [I know that the compiler claims if I do this but I don't want just memorize it].

Then, the book makes another mention: "A subclass not declaring an exception is similar to a method declaring it throws an exception that it never actually throws. This is legal".
Honestly here I don't understand this comparison: "a method declaring it throws an exception that it never actually throws". I can't get it. Just I figure out a method that declares a 'throws' in its signature and then not throwing anything (by "throw"). if someone can show an example it would be great.
But anyway I don't agree with this because if I override a method and then an exception occurs, it won't have caught because the try-catch block is declared in the superclass and not in the subclass.

Thanks!
 
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pablo,
Good question.

Consider this code:


This is good. The hop[() method doesn't declare an exception so test() doesn't need to either. Now we have an example that doesn't compile:



b.hop() declares a checked exception. But test() does not handle or declare it so that's a compiler error. Good so far? Now think about this one:




If the caller calls it with test(new Hopper()), all would be fine. But if the caller calls it with test(new Bunny()), we have a problem. The checked exception has nowhere to go.

Since the type of Hopper could be any subclass, this situation presents the compiler with a problem. Java solves that problem by not allowing you (the developer) to add checked exceptions to a method signature that you override. Since Java does not permit this, it knows that all subclasses of Hopper will not throw a checked exception from hop() so the test(Hopper h) method is happy.

Now off I go: Hop. Hop. Hop.
 
Pablo Napoli
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Jeanne! Now it's so so clear and it was a pleasure that the author of my book answered me!. These books are amazing, thank you very much again!
 
Marshal
Posts: 65050
247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To expand Jeanne's explanation.

The Hopper#hop() method will run and not throw an exception. Any use of the hop() method must therefore run and complete normally, but we can see that theBunny#hop() method warns that it doesn't complete normally. This method now behaves differently, and you can no longer apply the Liskov Substitution Principle. You cannot call hop() on a Bunny instance and use that method call the same way as on a Hopper instance. Even if the compiler sees there are empty {} in the Bunny#hop() method (you have to supply those empty {} or you get another compiler error), it recognises that you can no longer use a Bunny as a Hopper and you can no longer say that a Bunny IS‑A Hopper.

I don't think the compiler will look inside empty {} to check whether any exceptions are thrown. It believes the throws declaration and won't compile that method. After all, if Bunny compiled you could now write this:-Line 6 gives you a 10% chance of the exception being thrown; it is not necessary to write else because there is no possible path of execution from line 8 to line 10.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!