我一直在更新现有的库以抛出异常,以帮助改善使用该库的人员的调试。
起初,我认为我会定义特定于每个类的异常,但事实证明,大多数异常只是对现有运行时异常的扩展(例如,FooNegativeIntArgumentException extends IllegalArgumentException
,FooNullBarException extends NullPointerException
)消息。
定义新例外与使用现有例外的权衡有何不同?是否有任何惯例/最佳实践?
此外,鉴于需要向后兼容性,这些异常中的大多数(如果不是全部)都是运行时异常。
答案 0 :(得分:15)
这里是my take on why we have different types of exception and when to create custom exception types(注意:这使用.NET类型作为示例,但相同的原则适用于Java和使用结构化错误处理的任何其他语言)。在这里发布完整的答案可能太长了,所以我将发布两个关键摘录。
何时抛出不同类型的异常?为每个可以以不同方式编程处理的症状抛出不同类型的异常。
- 醇>
何时创建自定义异常类型?当您需要使用其他信息注释异常时,创建自定义异常类型,以帮助以编程方式处理症状。
在您的情况下,听起来您的自定义异常类型不会填补使用标准异常可以传达的症状的空白,并且它们不会为程序化处理添加任何其他信息,因此不要创建它们。只需使用标准的。
答案 1 :(得分:8)
在不添加任何此类值的情况下扩展例外是完全浪费时间并导致持续的维护成本,这是最好的避免。
使用标准例外。
这并不是说你永远不应该使用自定义异常,而不是在你出现的用例中。
此外,在创建自定义异常时,它们应该与导致它们的条件相关,而不是与它们可能抛出的类相关。可以将它们与业务/功能区域相关联,因为导致异常的错误条件可能以这种方式相关,并且它将提供有用的过滤技术。
答案 2 :(得分:6)
您应该支持使用标准异常,并使用涵盖您所描述的未经检查的异常的Java平台库集。重用例外具有以下好处:
使您的API更易于学习和使用,因为它符合程序员已经熟悉的既定惯例
更少的异常类意味着更小的内存占用,减少加载类所花费的时间。
答案 3 :(得分:2)
调用者是否需要捕获FooNegativeIntArgumentException而不是IllegalArgumentException?
我的猜测是它几乎不会发生,所以我会坚持使用基本的例外情况,直到你遇到需要这种区别的情况为止。
答案 4 :(得分:1)
权衡?很多工作,很多代码需要维护,时间就是金钱。我建议:只有在需要过滤日志,细粒度异常处理或调试(为特殊异常类型设置断点)时才定义新异常。
答案 5 :(得分:1)
我使用明确定义的异常来为客户端代码提供更多控制。如果客户想要,他们可以抓住IllegalArgumentException
,如上例所示。如果他们需要更多控制,他们可以捕获各种类型的异常。例如,考虑一个可能抛出IllegalArgumentException的两个子类的方法。如果你不是子类,则必须进行字符串解析或其他一些废话来确定抛出异常的实际原因。用户定义的类型解决了这个问题。