Java interface throws Exception best practice [closed]

Answer 1

Better have an idea what exceptions you need to throw later. There's the so called Liskov substitution principle, which recommends not to throw exceptions in subclasses that would not be thrown by the super class.

Liskov substitution principle aka. design by contract: http://en.wikipedia.org/wiki/Liskov_substitution_principle

If you are uncertain which Exception need to be thrown, use "throws Exception" (even if it is uncool). Just do not allow unexpected behaviour by implementing classes when they throw exceptions where they weren't planned by you.

The worst case would be a programmer who desperately throws runtime exceptions because of a lack of throws-declarations.

Answer 2

Think of checked exceptions as optional return values. The API whose methods return Object is understandably rare, and the same principle should apply for checked exceptions.

Answer 3

I prefer to throw Java standard subclass of RuntimeException. This gives the flexibility of allowing the Exception to propagate or be caught without having references to your API.

There are many subclasses to choose from http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html

Often I use IllegalStateException or IllegalArgumentException

Answer 4

I can appreciate trying to give the implementers some flexibility, but the exception is part of the API, so you should put some thought into what (checked) exception(s) makes sense.

By saying throws Exception, you are not helping the clients of the interface understand what kinds of failures are expected to give them a chance to react to them appropriately. You can consider akin to accepting a method parameter of Object to allow implementers to decide what arguments they can accept. Its good for the implementer, but a nightmare for the clients of the interface.

Answer 5

in general, throwing an exception means one of the two options:

1. asking the caller to take an action based on something that happened, usually hoping he has a broader / better understanding of the situation to take a decision
2. Notify the caller that the action failed beyond repair

focusing on the first type throwing specific exceptions is a good idea and the called can than do:

try {
} catch (ServerIsBusyException ex) {
    // wait 10 sec and continue / try another server
} catch (BadUserNameException ex2) {
   // try another name
} ....

second type is usually RuntimeException s that means an unexpected situation

see a good explanation in this answer

Answer 6

The reason for saying that an interface method declaring to throw the base class Exception is bad practice is because it would in fact make throwing an instance of that very base class a legal implementation of the interface, which is what you clearly want to avoid.

This is why you would only use specialized/custom exception types in your signatures.

I wouldn't go as far as saying that an interface should not declare a throwing of any Exception in advance, as someone said in his answer previously, because the interface is in fact not free floating.

You, as the one declaring the interface, invoke or use the methods in a certain way, and you make assertions on how the methods will be used by your side of the code.

It is in fact a contract that you create. And exceptions are a part of that contract. In fact the one using the interface (not the one implementing it) will be done with his work way before an implementation may exist.