Hi,

Jama schrieb:

IMO, throws Exception is not a very good practise. It forces you to
explicitly catch all Exceptions, including RuntimeExceptions, which may
not be wanted.
In your case, I'd say, you define a own Exception class that can be used
by programmers to encapsulate their own Exceptions:

<code>
  public class MyException extends Exception {
    public MyException (String message) { super(message); }
    public MyException (String message, Exception cause) {
super(message, cause); }
  }
  public interface MyInterface {
    public void instantiateThisMethod() throws MyException;
  }
</code>

In this way, users of you interface know what they must catch (checked
exception MyException).

However, if you define an interface, you should also define what
exceptions are thrown and in which cases a method will throw a checked
or a runtime exception, and of what type that exception will be.
Programmers will have to follow that contract.

Tobi.

In this case, the use of RuntimeException (by the implementing
programmer
) is better because you do not have to specify it in the throws clause.

If there is no reason for an abstract method to throw one or more
specific
exception, the use of RuntimeException by the implementing programmer
seems really better.

http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

P.S: sorry for my bad english. :-)

That's a fundamental problem, which is inherent to the way Java uses interfaces
and checked exceptions.   A throws clause is a promise (to the caller of the
method) that it will /NOT/ throw anything except the indicated exceptions (plus
unchecked ones).  Not having a throws clause at all is a blanket promise not to
throw (checked) exceptions.

Personally, I have come to doubt the value of this kind of promise (or, more
accurately, come to doubt the value of having the compiler police it so
relentlessly), but that's the way Java works, so that's what we have to live
with.

So the question is, what kind of promise is it appropriate to impose on the
people implementing your interfaces ?  It's a tricky design question.  On the
one hand (as every user of Java's IO classes knows), having too many throwable
exceptions is a serious pain for the user of the interface.  On the other hand
the people implementing the interfaces want as much freedom as possible.  It's
your job to balance the conflicting interests.

I would tend to favour the users of the classes, myself.  Unless the interface
is one that has an inherent (i.e. visible to any /user/ of the interface)
failure mode, then don't permit it to fail with a checked exception.  If it
/does/ have such a failure mode (which is rather common, admittedly), then as
Tobias has already suggested, define your own exception class (which can be
subclassed by interface implementers) and declare that.  If the developers
still complain then remind them that exceptions can be chained, and otherwise
ignore them ;-)

Also, don't forget the value of unchecked exceptions.  There is nothing wrong
with using them -- provided you do it with discretion.  They are appropriate
for anything that the user of the interface shouldn't be /forced/ to handle on
every call.  That broad class of events includes failure modes which should be
found and eliminated by testing.

Whatever you do, don't declare "throws Exception" !

   -- chris

I think the process should start by an effort to determine what
exceptions a user of the interface should be expected to know about and
handle specifically. All of those should be documented with throws
clauses and @throws Javadoc comments.

It doesn't matter that some implementations may not throw all of them.
It does matter that the user of the interface needs to be prepared to
deal with any of them, and needs to know what they mean.

If there is a generic "something broke" condition that the
interface-user cannot do much about, there may be a case for the
implementer extending RuntimeException.

Throwing Exception from everything does not tell the user of the
interface anything about what to prepare for, or how to interpret
exceptions.

Patricia