I am maintaining some code that has stretched my understanding of exceptions and interfaces. After tinkering around with some code (at bottom) the rules seem to be
* a method implementing an interface may or may not throw the interface method�s declared exceptions
* a method implementing an interface must not throw any exceptions not also thrown by the interface�s method
* a method may declare an exception as being thrown but never actually have any code to throw the exception
Am I getting all that right? It seems a little bizarre and inconsistent to me.
Thanks in advance all for your help!
You are thinking from the point of view of someone implementing the interface. Try instead thinking from the point of view of someone using such an object.
That person only has the interface declaration to go with. Therefore, they write their code to handle the exceptions described in the interface.
If your implementation were allowed to throw additional exceptions, that person's code would be broken, because it could not handle them. Therefore, you are not allowed to do so.
On the other hand, if your code happens not to throw some of the declared exceptions, their code will work just fine. It still needs the exception handling, because they might later plug in someone else's implementation, which does throw them. But, providing your object still fulfills the contract of the interface, yours works fine.
One reason that you are allowed to declare that a method throws an exception that its implementation currently does not is that the method may be overridden by an implementation that does throw that exception. Again, think from the point of view of a person using your method. They need to know what exceptions any implementation could throw, not just what your current implementation throws.
Originally posted by Justin Fox:
umm, I thought that interfaces, had to just have abstract methods,
and not be concrete?
well in an interface, you dont have to declare a method abstract,
when you declard that :
will that compile?
There is nothing concrete about declaring that a method might thrown a specific exception. Concrete method impiles a code block which there is none. The 'throws java.io.IOException' is only part of the method signature.
Yes, the code compiles. My example above if from real life experimental, compiled code...except for teh line that says 'will not compile' of course.
I have two questions regarding this:
Couldn't we simply state that the rules (concerning exceptions) for interface method declarations are just the same as for method declarations in classes that are to be subclassed and overwritten?
Or do you know any difference or (well...) exception between concrete and abstract methods regarding exceptions?
And: Is it true that the only sense in declaring an exception being thrown in an interface is not to allow any other (not inherited) exception?
e.g. you don't want the method foo(implemented in concrete classes) to throw - say - a FileNotFoundException, then you declare foo in the Interface as
void foo () throws ObjectStreamException;
Now, implementing classes must not have a foo method that declares to throw subclasses of IOException other than ObjectStreamException.
My question is, is this the only sense of declaring Exceptions in an interface?
Years ago we were required to submit "run time documentation" for batch programs. The people who audited these documents were real sticklers for detail, but they refused to publish any rules or guidelines about how to pass their inspections. So it was pretty much trial and error, one field at a time. Calling a method that might throw new, unexpected exceptions reminds me too much of that process.