我正在定义一个新的接口API...诚然,这不是我经常做的事情。我想定义抛出异常的接口方法,以便为实现者提供一定的灵活性。然后,他们可以选择抛出一个异常,抛出一个更具体的Exception子类,或者什么都不抛。我已经读过几次了,虽然允许实现类这种灵活性是好的,但用“抛出异常”来定义接口方法也是不好的。相反,建议对异常进行子类化(例如MyException)并抛出子类。对这种做法的解释还不够详细,所以有人能详细解释一下这种最佳做法吗?谢谢。
发布于 2013-12-11 21:40:06
我很欣赏试图给实现者一些灵活性,但是异常是API,的一部分,所以你应该考虑一下(选中的)异常是有意义的。
通过说throws Exception
,您并不是在帮助接口的客户端理解什么类型的失败会给他们一个机会对它们做出适当的反应。您可以考虑类似于接受Object
的方法参数,以允许实现者决定他们可以接受哪些参数。这对实现者来说很好,但对接口的客户端来说却是一个噩梦。
发布于 2013-12-11 21:40:08
最好知道以后需要抛出哪些异常。有所谓的Liskov替换原则,它建议不要在超类不会抛出的子类中抛出异常。
Liskov替换原理,又名。契约式设计:http://en.wikipedia.org/wiki/Liskov_substitution_principle
如果你不确定需要抛出哪个异常,使用“抛出异常”(即使它不酷)。当类抛出异常时,不要允许意外的行为,因为类不是你计划的。
最糟糕的情况是程序员因为缺少抛出声明而拼命抛出运行时异常。
发布于 2013-12-11 21:39:42
我更喜欢抛出RuntimeException
的Java标准子类。这提供了灵活性,允许异常在不引用API的情况下传播或捕获。
http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html中有很多子类可供选择
我经常使用IllegalStateException
或IllegalArgumentException
https://stackoverflow.com/questions/20530221
复制