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: 
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.
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`