围绕RuntimeException或Error设计Application Exception层次结构会更好吗？

Question

  

可能重复：
  Unchecked exceptions in Java: Inherit from Error or RuntimeException?

看看我们的应用程序如何进行错误处理，我们一直在从已检查的ExceptionHierarchy（例如Exception - ＆gt; ApplicationException - ＆gt; SomethingSpecificBadHappenedException）中稳步转移，因为在很多情况下我们有许多长调用链，它们只传递了ApplicationException，并且它增加了一些价值，但却使我们的API变得混乱（我们越来越同意在Effective Exceptions中表达的观点。

在围绕未经检查的异常重新设计我们的错误处理时，与“故障障碍”方法保持一致，我们最初已开始使用基于RuntimeException的层次结构，类似于Spring Data Access layer

中的示例

我们一直在开始怀疑让它们从Error中退出是否更为明确，尤其是它会让我们做类似的事情：

} catch (Exception e) {

在我们的应用程序中的许多地方，但随后区别于：

} catch (Throwable t) {或} catch (Error err) {

虽然我无法想到遵循此API的API的主要示例，但感觉更干净。我正在寻找最佳常见API的示例，这些API根据我们的异常/错误层次结构的根源，或者对样式或功能差异的评论应该优先考虑一个根。

Answer 1

规则是，不要创建源自Error的应用程序例外。 Error层次结构仅用于JVM和核心库报告的不可恢复的错误。

我知道没有违反此规则的主要API。

Answer 2

您希望扩展RuntimeException。

总的来说...... 听起来真正的问题是，您的组织认为最好只在任何地方抛出ApplicationException而不是抛出特定的，有意义的，记录良好的异常。

从你引用的文献中可以看出：

  

<强>应急
  预期的条件要求可以用方法的预期目的表达的方法的替代响应。该方法的调用者期望这些条件，并有一个应对它们的策略。

     

<强>故障
  一种意外情况，阻止方法实现其预期目的，如果不参考方法的内部实现，则无法描述。

像“一切都未经检查”这样的单一方法就像“一切都被检查”一样糟糕（在我看来，更糟）。应用Java设置的相同约定：
如果条件是编程错误，那么它是RuntimeException 如果条件是调用者可能期望并且能够处理的有意义的事情，请使用Exception 如果条件是系统错误（如资源不可用），这会阻止任何有意义的操作继续进行，请使用Error（但这种情况非常罕见）。

Answer 3

除了其他答案之外：如果不在“正常”程序逻辑中重新抛出，则不应捕获Error或Throwable。我可以想到捕获Error的子类的主要原因是：你正在使用自己的类加载系统，并希望隔离破碎的插件。

ThreadDath的JavaDoc说：

  

只有在异步终止后必须清理该应用程序的实例时，才应该捕获该类的实例。如果ThreadDeath被一个方法捕获，重要的是它被重新抛出，以便线程实际死掉。