【发布时间】：2011-01-17 11:05:28
【问题描述】：
有时候，我明白
try {
} catch(Throwable e) {
}
有时
try {
} catch(Exception e) {
}
有什么区别？
【问题讨论】：
【发布时间】：2011-01-17 11:05:28
【问题描述】：
通过捕获Throwable，它包含了Error 的子类。您通常不应该这样做，除非在您想要记录或以其他方式绝对处理所有可能出错的线程的最高“catch all”级别。它在框架类型应用程序（例如应用程序服务器或测试框架）中更为典型，它可以运行未知代码并且不应该受到该代码出错的任何的影响，因为尽可能的。
【讨论】：
-
这里最好解释一下层次结构。
-
此答案的上下文：Throwable 包含 Error 和 Exception 作为子类，因此第一个 try/catch 包含第二个但通常过于宽泛。
-
它还包括用户定义的 Throwable 直接子类和 Throwable 本身的实例。没有什么能阻止你写
throw new Throwable();，所以这是真正抓住一切的唯一方法。 -
虽然被接受，但这并没有回答这个问题，因为大多数答案都描述了捕获异常和 Throwable 的最佳实践，而问题是关于差异（如何时使用 which when I DO想要任何一个）。 “它包括错误子类的东西”是指定的唯一区别，它确实是一个全面的答案：什么是错误？为什么包含它很重要？还有其他区别或最佳做法吗？
-
@OdedNiv “什么是错误？为什么包含它很重要？”您可以在另一个问题中提问。
【讨论】：
-
令人惊讶的是，在得到这个答案 4 年后，大多数“代码分析”工具仍会将捕获 throwable 报告为 critical 错误。日志记录是捕获 Throwable 的一个非常正当的理由。多年的服务器开发告诉我 1) 尽管收到
Error和 2) 除非有日志记录，否则您可能永远不会收到发生 OOM 的通知，这让您想知道为什么服务器开始表现得“有趣” -
programmatically unrecoverable到底是什么意思？它是否如此严重，以至于我们在捕获它（日志记录等）之后基本上不能调用任何 Java 方法，而没有机会从 JVM 获得不可预测的行为？ -
Its subclass RuntimeException indicates a programming error：不确定我是否同意这个说法。如果这是真的，这意味着所有预期的异常都应该是检查异常。如果我预计某些事情可能会失败并且我的应用程序无法恢复，但我希望至少抛出一个有意义的异常怎么办？在这种情况下使用检查异常似乎没用，并且会创建样板代码。
Throwable 捕捉到了所有东西，甚至是默认抛出的 ThreadDeath 以从现在已弃用的 Thread.stop() 方法中停止线程。因此，通过捕获 Throwable，您可以确保您永远不会离开 try 块而至少要通过您的 catch 块，但您应该准备好同时处理 OutOfMemoryError 和 InternalError 或 StackOverflowError。
捕获Throwable 对于将各种请求委托给外部代码但本身可能永远不会终止以保持服务活动的外部服务器循环最有用。
【讨论】：
Throwable 是Exception 和Error 的超类。在正常情况下，我们应该始终捕获Exception 的子类，这样根本原因就不会丢失。
只有在您发现可能出错且无法控制您的 Java 代码的特殊情况下，您才应该捕获 Error 或 Throwable。
我记得捕获 Throwable 以标记未加载本机库。
【讨论】：
我看到人们使用 Throwable 来捕获一些由于基础设施故障/不可用而可能发生的错误。
【讨论】：