java.lang.Error是否常于主线程外抛出？是否需捕获其他线程Throwable？

1. java.lang.Error是否通常会在主线程之外抛出？ #

当然不是，Error完全可能在任何线程里抛出，不管是主线程还是后台工作线程。举几个常见场景：

• 当某个工作线程循环分配大量内存时，触发OutOfMemoryError是很普遍的情况；
• 如果工作线程里有深度递归调用，也会抛出StackOverflowError。

主线程并没有“专属”Error的抛出场景，任何线程只要遇到虚拟机层面的严重故障，都可能抛出Error。

2. 是否需要在其他线程添加捕获所有Throwable的代码块来记录故障？ #

这绝对是值得重点关注的场景，而且我非常建议你这么做。

先回到Java文档的定义：

Error是Throwable的子类，代表合理应用不应尝试捕获的严重问题。

但这里的核心矛盾是你使用的库会捕获并忽略用户回调中的所有Throwable——包括Error。这会带来两个关键风险：

1. 回调中抛出的Error被静默忽略，你完全不知道发生了虚拟机级别的严重故障；
2. 如果工作线程中回调以外的代码抛出Error，会直接导致线程终止，但主线程仍在运行，你无法感知后台任务已经挂掉，应用可能处于不一致状态（比如未完成的任务、未释放的资源）。

所以我的具体建议是：

• 在工作线程的顶层入口（或者线程池的任务包装逻辑里）添加全局的catch (Throwable t)块，专门记录详细日志——包括异常类型、完整堆栈轨迹、线程名称等关键信息；
• 文档里说“不应捕获Error”，指的是不要试图恢复Error导致的致命故障，而非不能记录日志。记录日志是为了让你及时发现问题，而非强行让线程继续运行；
• 另外，库捕获并忽略所有Throwable的做法不符合最佳实践。如果可能，你可以在自己的回调代码里先单独捕获Error，记录日志后再重新抛出（哪怕库还是会忽略，至少你留了故障痕迹）。

总的来说，静默失败是排查问题的噩梦，尤其是后台线程的故障。添加这样的捕获逻辑，能帮你及时发现严重问题，避免应用在不健康的状态下继续运行。

内容的提问来源于stack exchange，提问作者Steven