我正在定义一个新的接口 API...诚然，这不是我经常做的事情。我想定义接口方法来抛出一个异常，以便为实现者提供一些灵活性。然后，他们可以选择抛出 Exception，抛出更具体的 Exception 子类，或者什么都不抛出。我已经读过几次，虽然允许实现类的这种灵活性是件好事，但用“throws Exception”来定义接口方法也是不好的。相反，建议对 Exception（例如 MyException）进行子类并抛出子类。对这种做法的解释缺乏细节，所以有人可以详细阐述这种最佳实践吗？谢谢。
我可以理解尝试给实现者一些灵活性，但异常是API的一部分，所以你应该考虑一下（检查的）异常是有意义的。
通过说 ，您没有帮助接口的客户端了解哪些类型的故障会给他们一个机会来适当地对它们做出反应。您可以考虑类似于接受 的方法参数，以允许实现者决定他们可以接受哪些参数。它对实现者有好处，但对接口的客户端来说是一场噩梦。throws ExceptionObject
最好知道以后需要抛出哪些异常。有所谓的Liskov替换原则，它建议不要在子类中抛出不会由超类引发的异常。
里氏替换原理又名。合同设计：http://en.wikipedia.org/wiki/Liskov_substitution_principle
如果不确定需要引发哪个异常，请使用“引发异常”（即使它不酷）。只是不允许通过实现类来实现意外行为，当它们引发不是由您计划的异常时。
最糟糕的情况是程序员由于缺乏抛出声明而拼命抛出运行时异常。
