Question: I'm defining a new interface API... admittedly not something I do all that often. I'd like to define the interface methods to throw an Exception to allow some flexibility for the implementers. They can then choose to throw an Exception, throw a more specific subclass of Exception, or throw nothing at all. I've read a couple of times that while its good to allow implementing classes this flexibility, it's also bad to define the interface method with "throws Exception". Instead, it's recommended to subclass Exception (e.g. MyException) and throw the subclass. The explanations for this practice were lacking in detail, so can someone elaborate on this best practice please? Thanks.

Answer: 
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.
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](https://stackoverflow.com/a/2190175/41576)