• Post Reply Bookmark Topic Watch Topic
  • New Topic

Perplexed: Exceptions and Interfaces  RSS feed

 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

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!

Stu


 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are right about what is and is not allowed, but you are wrong that it's haphazard. In fact, it all makes sense.

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.

HTH
 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Try instead thinking from the point of view of someone using such an object."

That certainly did the trick...great insight on your part. Thanks for the clear explaination!

Stu
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might want to read about Liskov's Substitution Principle, which is the driving force behind this and other things, like the way overriding methods can change access modifiers, covariant return types in Java 5 etc. pp.
 
Justin Fox
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
it's "understood".

when you declard that :



will that compile?

Justin..
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nicely done, Peter. I tried to say exactly the same thing a while ago, but you did a lot better job.
 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
it's "understood".

when you declard that :



will that compile?

Justin..


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.
 
Burkhard Hassel
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi cowboys!

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?


Yours,
Bu.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The objective again is to warn folks who will use the interface about what to expect. Telling them the method can and might throw ExceptionA tells them they have to do something to handle it or pass it along. What prevents an implementation from throwing ExceptionB is the rule we've been talking about - it can't throw anything that the original contract didn't warn the user about.

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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!