This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
Can you please provide me an explaination for the following:-
1. If a method in an interface is declared to throw an Exception then the implementation of that method in a class which implements the interface need not throw that exception. Why is it designed so, I am missing the rationale behind this behaviour.
Lets say I want the client to invoke only a given set of methods and I provide him an interface with those methods. Since I have declared methods in the interface which throw exceptions, I expect the client to handle those exceptions. Shouldn't it be mandatory for the method declaration in the implementor class to throw those exceptions
It is possible that the implementation does not have the need of that exception. Suppose you create an interface for doing IO action. But someone provides an implementation that does not use IO but stores everyting in memory. An IOException will never get thrown and it is not necessary for the interface implementor to declare the exception in the throws clause.
In the other way around however you can not throw more exceptions in your implementor that are not specified by your interface.
Note this subtle point: if a client writes their code to use class "Test" directly, then they won't have to catch Exception, but that's OK, because Test.print() won't throw it. But if they write their code to use Test through the TestInterface interface, then they will have to catch it, because a reference to the interface may point to an object that can throw.
A general rule of implementing and extending is you can make your new class or interface "less restrictive" but not "more restrictive". If you think of the requirement to handle an exception as a restriction, an implementation that doesn't declare the exception is less restricive. Anybody who codes to the interface will not have trouble with your class.
What if you tried to go the other way and throw exceptions not declared by the interface? That would be "more restrictive" and clients who coded to the promises of the interface would be surprised in a bad way when you threw the exception.
Parameters get the same treatment. If the interface says a method takes a HashMap and you implement and say you take a Map, you are less restrictive. If the interface says the parameter is a Map and you implement it with a HashMap parameter, that's more restrictive. Somebody who coded to the interface would think they could send you some other Map and would get another bad surprise when they try.
The compiler enforces the rule and prevents such surprises. Three cheers for the compiler!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi