• 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

Checked exception and interface.

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

I have interface with abstract method, that throws checked exception and class that implements that interface and method.
Am I obligated to declare that implemented method throws exception mentioned in interface declaration?

As for my test it is not the case.

Then why anybody will declare method with checked exception in interface?

Please clarify.

Thank you.

 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because a class that implements the interface might thrown the given exception. A overridden method can't throw a new or broader checked exception.
 
Michael Rootman
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, but I cannot see how your post answers on my question.

Consider following code:



ClassB implements TestInterface, so I have to implement doIt method. But I do not have to declare that this method throws IOException.
Class A initializes ClassB and I can invoke doIt method without handling exception.
So why should I ever need to declare in interface that doIt method throws exception?
 
David Marco
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Imagine that one of your implementer classes need to throw an exception:

The avobe code don't compile, due to an overriding/implementing method CAN'T THROW a new or broader checked exception. So, you declare the exception in the interface, and later choose either throw or not throw such exception in a implementer class. The key point is that if you don't declare the exception in the base class, a subclass can't never throw such a exception if needed.
 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


ALL of the above are legal and will compile.

The interface declaration is just giving you the "Freedom" to throw an IOException or any of its subclass exceptions when you go to implement.

You do not ever have to agree to throw any of the checked or unchecked exceptions declared in the Interface.

You could throw a "narrower/subclass" FileNotFound Exception at implementation but cannot throw a "broader" exception like Exception.

The following would throw Compile Error:


Hope this helps! I was reading/learning about this today so let me know if there any faults.
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ryan Anderson wrote:
ALL of the above are legal and will compile.



Sorry, it won't compile, because you tried to overload the method doIT() in classB and failed one of the rules for overloading:

Overloaded methods MUST change the argument list


The key explanation of your post and David Marco is true.

cheers
Bob
 
Ryan Anderson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


My fault. The method signatures were legal overrides but you can only have one legal override per method and I had three.

I just copied the above out of eclipse. Same method signatures but different classes.
 
Michael Rootman
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

I get the point. Thank you for explanations.
My next question is such freedom to choose can impose issues?

Let’s take class that implements TestInterface (ClassB) and exception thrown on the doIT method.
Any usage of this method (ClassA) will obligate to catch declared exception, right?
Later I can review my ClassB and decide that I do not want to throw exception. I am allowed to.
What will happened with ClassA(assuming it is not going to be recompiled), that still tries to catch exception that never thrown?

Thank you.
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If its a checked exception then it will give a compile time exception..
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I have discovered a strange thing while studying the interfaces part. Consider the following code:

Why does this code compile? ClassCastException is at the same level in the inheritance tree as IllegalArgumentException. They are both a direct subclass of RuntimeException. So they don't have a IS-A relationship with each other. And look at this:

IllegalArgumentException is a subclass of RuntimeException, so RuntimeException is a broader exception! So, why does this compile?
I hope someone is able to help me with this. I have installed Java version 1.6.0_17

Kind regards, JT Hofstra
 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The rule for overriding method is that: you cant declare broader or new checked exception for overriden method
RuntimeException or any of its subtype are considered as unchecked exception. So there is no problem in declaring new or broader exceptions.

Note that overriden rule is applied to only checked exception
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic