Java、类特定异常与标准异常

这是 my take on why we have different types of exception and when to create custom exception types (注意:这是以.NET类型为例,但同样的原理适用于Java和任何其他使用结构化错误处理的语言)。作为一个完整的答案发布在这里可能太长了,所以我只发布两个关键的摘录。

1. 何时引发不同类型的异常?为每个症状抛出不同类型的异常,这些异常可以以不同的编程方式处理。

2. 何时创建自定义异常类型?当需要用附加信息注释异常以帮助编程处理症状时,创建自定义异常类型。

在您的案例中,听起来您的自定义异常类型并没有填补使用标准异常可以传达的症状中的空白,并且它们没有为编程处理添加任何额外信息,因此不要创建它们。用标准的代替。

在不增加任何价值的情况下扩展例外情况是完全浪费时间,并且会导致持续的维护成本,这是最好避免的。

使用标准例外。

这并不是说您永远不应该使用自定义异常,只是不应该在您所呈现的用例中使用。

此外,在创建自定义异常时,它们应该与导致它们的条件相关,而不是与可能从中抛出它们的类相关。将它们关联到业务/功能领域是可以的,因为导致异常的错误条件可能以这种方式相关,并且它将提供有用的过滤技术。

从 Effective Java

您应该赞成使用标准异常,并使用Java平台库集合来检查您所描述的异常。重用异常具有以下好处:

使您的API更容易学习和使用,因为它与程序员已经熟悉的既定约定相匹配。

更少的异常类意味着更小的内存占用和更少的加载时间。

调用方是否可能需要捕获FooneGativeIntargumentException而不是IllegalArgumentException?

我的猜测是,这几乎永远不会发生,所以我会坚持基本的例外,直到你有这样的情况下,这种差异可以看出是必要的。

权衡?很多工作,很多代码需要维护和 时间就是金钱 . 我建议:只有在筛选日志、细粒度异常处理或调试(为特殊异常类型设置断点)时才定义新的异常。

我将使用显式定义的异常来赋予客户机代码更多的控制权。如果客户愿意,他们可以 IllegalArgumentException 就像上面的例子一样。如果他们需要更多的控制,他们可以捕获个别类型的异常。例如,考虑一个可以抛出IllegalArgumentException的两个子类的方法。如果没有子类,则必须进行字符串分析或其他一些无意义的工作,以确定引发异常的实际原因。用户定义的类型解决了这个问题。