捕获已检查的异常[重复]后重新抛出RuntimeExceptions

Question

此问题已经在这里有了答案：

What issues may ensue by throwing a checked exception as a RuntimeException?（6个答案）

关闭6年前。

在Java中，已经观察到在处理RuntimeException之后有重新抛出Checked Exception的约定。

这种方式有好有坏。当编译器强制通过Checked Exception处理某些内容时，开发人员可以通过捕获它并将其重新抛出为RuntimeException来摆脱它。

有人可以解释这种情况是否可以视为一种好的做法吗？如果是这样，这种方法会减少出错的可能性，还是会使代码库变得不稳定？

Answer 1

实际上是对handling检查的异常的不适当尝试，导致代码库不稳定。通常，您将拥有：

try {
   //stuff
} catch (IOException e) {
   log.error("Failed to do stuff", e);
   throw e;
}

然后进行下一个升级，您将不得不再次处理它，通常将其全部记录下来并弄乱日志文件。如果您不重新投掷，将是[[甚至更糟：

try {
   // do stuff
} catch (IOException e) {
  return null;
}

现在调用代码不知道出了什么问题，更不用说什么了。与这些尝试相比，这实际上可以完全满足应用程序逻辑的需求：
try {
  // do stuff
} catch (IOException e) {
  throw new RuntimeException(e);
}

现在，异常可以自由地在调用堆栈中传播，直到到达定义明确的
exception barrier

，在这里：

中止当前的工作单位；
1. 将日志记录在一个统一的位置。

简而言之，要决定是抓住还是抛弃，只需问问自己这个问题：

此异常的发生是否必须中止当前的工作单位？

如果
• 是

：抛出未经检查的异常；如果

否

：在catch块中提供有意义恢复代码。 （否，记录无法恢复。）>[从多年的实际经验中，我可以告诉您，所有可能的检查异常中，有90％以上是“异常中止”类型，在发生的位置不需要任何处理。

关于检查异常的语言功能的争论

今天，检查异常在语言设计中被广泛认为是失败的实验，而以下是关键参数：

由API创建者决定客户端代码中其异常的语义。

Java的推理是可以将异常分为

由于编程错误导致的异常（未经检查）；
1. 由于程序员无法控制的情况造成的例外（已检查）。
2. 尽管这种划分在某种程度上是真实的，但是只能从客户端代码的角度定义它。更重要的是，在实践中这并不是一个非常相关的部门：真正重要的是

   必须在什么时候处理异常

。如果要延迟处理，则在异常障碍处，检查异常不会获得任何好处。如果提早处理，那么只有有时从检查的异常中获得少量收益。实践已证实，正如每位Java专业人士所见证的那样，检查异常所带来的任何收益都与对现实项目造成的现实损害相形见d。 Eclipse和其他IDE也应该受到指责，建议经验不足的开发人员将代码包装在try-catch中，然后想知道在catch-block中写什么。

[无论何时遇到throws Exception的方法，您都找到了另一个鲜活的证据证明受检查的异常的不足。

Answer 2

受检查的异常

Answer 3

术语“

可以摆脱它

Answer 4

根据上下文可能会也可能不会，但可能不是。

Answer 5

一般规则是：当调用者得知通知后可能能够进行某种恢复时，您将抛出一个已检查的异常。否则，抛出未经检查的异常。