• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

OCA/OCP Java SE 7 Programmer I & II Study Guide (K/B), need help confused on chapter 2 overriding.

 
Joe McTigue
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm studying for the OCA Java SE 7 Programmer I certification exam and was reading chapter 2 and came across the following:

page 103, chapter 2, 8th bullet down of the rules for overriding a method:

The overriding method can throw narrower or fewer exceptions. Just because
an overridden method "takes risks" doesn't mean that the overriding subclass'
exception takes the same risks. Bottom line: An overriding method doesn't
have to declare any exceptions that it will never throw, regardless of what the
overridden method declares.


Then on page 105 of the same chapter in the Exam Watch section it gives the following
example:


Is the error the rule on page 103 I listed above, or is it in the code example in the exam watch section listed in code?
Or am I just losing my mind over thinking this? :-)

Regards,
Joe
 
Henry Wong
author
Marshal
Pie
Posts: 22089
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe McTigue wrote:
Is the error the rule on page 103 I listed above, or is it in the code example in the exam watch section listed in code?
Or am I just losing my mind over thinking this? :-)


The first rule you quoted refers to what is allowed during an override of the method. The code example error was caused how you are using the methods -- and that is regardless of an override happening or not. You would get the same error if you had this code at line 10.



In other words, you would get the same compiler error, even if you didn't use the Dog2 class.

Henry
 
Joe McTigue
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Henry,

First, thanks for taking the time to answer this.
Second, Could you explain a bit more in detail, I don't quite grasp what you are saying caused the error in the coded section.
Which line of code and why?

Thanks so much in advance for any further help.

-Joe
 
Henry Wong
author
Marshal
Pie
Posts: 22089
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe McTigue wrote:
Second, Could you explain a bit more in detail, I don't quite grasp what you are saying caused the error in the coded section.
Which line of code and why?


Take a look at this code...



This generates a compile error -- even though there are no Dog2 instances involved. If you can understand why this generates an error, then it is easy to see why your original code generates the same error.

Henry
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe McTigue wrote:First, thanks for taking the time to answer this.
Second, Could you explain a bit more in detail, I don't quite grasp what you are saying caused the error in the coded section.
Which line of code and why?

Let's see if I can clear some doubts.

The 1st statement (on page 103) is one of the rules for a valid override. As you know an overriding method has to have the exact same name and parameter list as the overridden method. The access level can be less restrictive but not more restricive, so you can override a protected method and make the overriding method public but not private). Another rule is about the exception list (that's the throws-clause in the method declaration). The overriding method can throw no exceptions, the same exceptions or narrower or fewer exceptions; but broader exceptions are not allowed. Let's illustrate with some code examples. Assume this base classAll these subclasses override the eat method correctly and thus will compileBut it's not allowed to (declare to) throw broader exceptions from an overriding method, so the following class does not compileAnother important remark: this rule only applies to the checked exception, because these exceptions are verified by the compiler. Runtime exceptions are not verified by the compiler, so you can (declare to) throw any runtime exception you want from the overriding method (even if the overridden method doesn't declare them). So this code will compile as wellIf you understand all of this, we are already halfway

Now it's time to write some code to use a few Animal classes (this code is very similar to the code snippet on page 105)In this code it's not anymore about the rules for a valid method override, because in this code we are not overriding a method (like in all the previous Animal classes). In this code we are just creating a few objects and invoking some methods on them. And again the compiler does a bunch of verifications to see if your code is valid and if your code violates one of its rules, you'll get a compiler error. If you compile the Zoo class you'll notice that compilation fails due to an error on line4, all other lines are valid. Do you want to know why? Fasten your seatbelt and read on!

Let's start with a very, very, very important rule: The compiler doesn't execute any code! So every compiler error you get, is because the compiler knows something is wrong without executing any line of code.

Now let's look at the code. On line1 a new Lion object is created and the reference variable lion (of type Lion) is refering to this newly created Lion object. On line2 the eat method is invoked, so the compiler needs to verify if you can execute the eat method. So the compiler checks the Lion class and notices a public eat method without parameters, so you can invoke this method. Then the compiler checks if the eat method in the Lion class contains checked exceptions in its exception list (because as you know checked exceptions must be handled or declared, otherwise you'll get a compiler error). The eat method in the Lion class doesn't have an exception list (no throws-clause), so this method doesn't throw any checked exceptions. So far the compiler is very happy with the code he sees
On line3 another (second) Lion object is created and the reference variable animal (of type Animal) is refering to this second newly created Lion object. The compiler is still a happy camper. On line4 the eat method is invoked, so the compiler needs to verify if you can execute the eat method. So the compiler checks the Animal class (and not the Lion class)! Remember: the compiler does not know the type of the actual object reference variable animal is refering to, the compiler only knows the type of reference variable animal (which is Animal). That's why the compiler checks the Animal class (and not the Lion class)! In the Animal class, the compiler notices a public eat method without parameters, so you can invoke this method. Then the compiler checks if the eat method in the Animal class contains checked exceptions in its exception list. The eat method in the Animal class has a throws-clause with two checked exceptions (ClassNotFoundException and IOException), so the compiler knows this method could throw a checked exception. Thus the compiler now has to check the handle-or-declare rule: does the code in the Zoo class handle or declare these checked exceptions. And then the compiler discovers the unthinkable: there is no try/catch block (to handle the exceptions) and the main method doesn't have a throws-clause with the checked exceptions (to declare the exceptions). So the code violates the handle-or-declare rule (for checked exceptions), the compiler is not amused at all and gives a compiler error at line4. The end!

Hope it helps!
Kind regards,
Roel
 
Joe McTigue
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Roel,

Thank you, this makes clear as day sense to me now.

Thank you,
Joe
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic