Designing an interface with exceptions

[Jim Sculley]

This is related to a previous post, the one that ended in a virtual punch up
- "Overriden method doesn't throw Exception, super may."

When you design an interface (and resulting classes) where exceptions may be
thrown how do you deal with the situation where different implementations
may or may not throw those exceptions.
I'm not considering the case where you might want to throw different
exceptions.

I'm looking for the most beautiful solution that can be mustered

Google for any of the numerous discussions on checked exceptions. I
recall one agonizingly long one within the past year in which this stuff
was covered in great detail. In the end, I was left unsure if I liked
or disliked checked exceptions.

Jim S.

 

[VisionSet]

This is related to a previous post, the one that ended in a virtual punch up
- "Overriden method doesn't throw Exception, super may."

When you design an interface (and resulting classes) where exceptions may be
thrown how do you deal with the situation where different implementations
may or may not throw those exceptions.
I'm not considering the case where you might want to throw different
exceptions.

I'm looking for the most beautiful solution that can be mustered

Chris, I know you have answered a similar question, thankyou. This is more
general.

TIA

 

[Chris Smith]

This is related to a previous post, the one that ended in a virtual punch up
- "Overriden method doesn't throw Exception, super may."

When you design an interface (and resulting classes) where exceptions may be
thrown how do you deal with the situation where different implementations
may or may not throw those exceptions.

If an exception has a logical meaning in the context of an interface
method, you declare it, along with documentation clarifying exactly when
it is thrown (though the general idea should be obvious). If your
client knows that they'll be using a specific implementation of the
interface that doesn't throw that exception, then they won't need to
worry about it anyway.

If an exception might be thrown by implementing code but *doesn't* make
sense from the perspective of someone using the interface, then you
write your own checked exception class that does make sense in that
context, and then rely on the implementor to nest their exception into
your own checked exception. For example, see the custom exception class
javax.mail.MessagingException and its uses in JavaMail. Declaring
IOException is a little too low-level for the JavaMail API, so an
IOException in the implementation of a mailbox will end up wrapped in
MessagingException before being thrown to a client.

I'm not considering the case where you might want to throw different
exceptions.

Okay, but that last bit also works for arbitrary exceptions in the
implementation, should the situation come up.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

When you design an interface (and resulting classes) where exceptions may
be thrown how do you deal with the situation where different
implementations may or may not throw those exceptions.

I don't know if this'll help any, and I know I've said it before, but...

Don't think of a throws declaration as an indication that a method /does/ throw
an exception, it is actually a promise /not/ to throw any (checked) exception
/except/ those mentioned.

With that in mind you may find it easier to constuct an interface that makes
sense.

-- chris

 

[VisionSet]

If an exception has a logical meaning in the context of an interface
method, you declare it, along with documentation clarifying exactly when
it is thrown (though the general idea should be obvious). If your
client knows that they'll be using a specific implementation of the
interface that doesn't throw that exception, then they won't need to
worry about it anyway.

If an exception might be thrown by implementing code but *doesn't* make
sense from the perspective of someone using the interface, then you
write your own checked exception class that does make sense in that
context, and then rely on the implementor to nest their exception into
your own checked exception. For example, see the custom exception class
javax.mail.MessagingException and its uses in JavaMail. Declaring
IOException is a little too low-level for the JavaMail API, so an
IOException in the implementation of a mailbox will end up wrapped in
MessagingException before being thrown to a client.


Okay, but that last bit also works for arbitrary exceptions in the
implementation, should the situation come up.

Okay. I'm happier apbout this now.
I think there should be some language syntax that allows implementors to
declare a non-inheritable 'I know this can not be thrown don't bother
callers with it' flag. A bit like the synchronized keyword.

 

[John C. Bollinger]

VisionSet wrote:




I don't know if this'll help any, and I know I've said it before, but...

Don't think of a throws declaration as an indication that a method /does/ throw
an exception, it is actually a promise /not/ to throw any (checked) exception
/except/ those mentioned.

I think that's a useful point of view. There is more to designing an
interface than the method signatures, however: one must also document
the expected behavior of implementations. Here, then, one must decide
whether it is a _requirement_ that the exception be thrown under some
specific (documented) set of circumstances, or whether it is optional
(also under some documented set of circumstances). If you cannot do
that in a generic way then you probably need a more abstract exception,
as Chris Smith discussed.


John Bollinger
(e-mail address removed)

 

[VisionSet]

If your
client knows that they'll be using a specific implementation of the
interface that doesn't throw that exception, then they won't need to
worry about it anyway.

The client won't but the client of the client will.
We are back to catching it and throwing R/T exception?

Specifically I have two classes one throws I/O exceptions, it talks to a
file.
The other is a cache that doesn't. I'd like both to present the same
interface to clients. So I need a nice name for an exception that describes
read/write or get/put problems, not that the latter will produce this
exception - DataTalkException?

Thanks Jim, and other Chris U. also!

 

[Steve Horsley]

This is related to a previous post, the one that ended in a virtual punch up
- "Overriden method doesn't throw Exception, super may."

When you design an interface (and resulting classes) where exceptions may be
thrown how do you deal with the situation where different implementations
may or may not throw those exceptions.
I'm not considering the case where you might want to throw different
exceptions.

I'm looking for the most beautiful solution that can be mustered

Chris, I know you have answered a similar question, thankyou. This is more
general.

Maybe I'm feeling argumentative tonight, but I think that if an interface
says it can throw an exception then you MUST code the user as though it
might. If you assume "Well, I know that the implementation I am using
actually doesn't." then you are commiting a crime. OK, the implementation
that you use _now_ may not, but what about the improved implementation if
the SAME INTERFACE that they replace it with in the next revision? You
have just planted a logic bomb. Think wilfil negligence.

There. Now I'm going to have another drink and then pick a fight with
the wife.

Steve.