在Java中，什么时候应该创建一个检查异常，什么时候应该是运行时异常？

Question

什么时候应该创建一个检查异常，什么时候应该创建一个运行时异常？例如，假设我创建了以下类：public class Account {    private float balance;    /* ... constructor, getter, and other fields and methods */    public void transferTo(Account other, float amount) {        if (amount > balance)            throw new NotEnoughBalanceException();        /* ... */    }}我应该如何创建我的NotEnoughBalanceException？它应该扩展Exception还是RuntimeException？还是我应该只使用它IllegalArgumentException？

Answer 1

总的来说，我认为Joshua Bloch在《有效的Java》中的建议最好地总结了您的问题的答案：对可恢复的条件使用检查的期望，对编程错误使用运行时异常（第二版中的项目58）。

因此，在这种情况下，如果您确实要使用异常，则应将其选中。（除非的文档transferTo()非常明确地指出，必须先使用其他Account方法检查该平衡，然后才能调用该方法，但这似乎有点尴尬。）

还要注意项目59：避免不必要地使用检查的异常，以及项目57：仅在特殊情况下使用异常。正如其他人指出的那样，这种情况可能根本不构成例外。false如果信用不足，请考虑返回（或者可能是状态对象，详细说明发生的事情）。

Answer 2

何时使用检查异常？老实说 以我的愚见...从来没有。我认为距我上次创建受检查的异常已有6年了。

您不能强迫某人处理错误。可以说，它会使代码更糟而不是更好。我无法告诉您遇到这样的代码的次数：

try {

  ...

} catch (IOException e) {

  // do nothing

}

而我有无数次编写这样的代码：

try {

  ...

} catch (IOException e) {

  throw new RuntimeExceptione(e);

}

为什么？因为条件（不一定是IOException；这只是一个例子）无法恢复，但无论如何还是被迫下咽，我经常被迫在执行上述操作和污染我的API之间做出选择，以一直传播检查的异常到（致命地）致命的顶部，并将其记录下来。

有一个原因是Spring的DAO帮助器类将已检查的SQLException转换为未检查的DataAccessException。

如果您遇到诸如对磁盘的写权限不足，磁盘空间不足或其他致命状况之类的问题，那么您希望产生尽可能多的噪音，而这样做的方法是...未检查的异常（甚至是错误）。

此外，检查的异常会破坏封装。

应该将检查异常用于“可恢复”错误的想法实际上是一厢情愿的想法。

Java中的检查异常是一个实验...一个失败的实验。我们应该减少损失，承认我们犯了一个错误并继续前进。恕我直言.Net通过仅具有未经检查的异常来解决问题。再一次，它具有从Java错误中学习的第二个优点。