在调度程序中捕获Throwable是一种好习惯吗？

Question

我宁愿说快速失败并且没有捕捉Throwable是一个很好的做法。 但是，如果请求处理器（如StackOverflowError）中出现未处理的异常，则可能会停止该任务。 这并不总是听起来不错。 我宁愿一遍又一遍地捕获StackOverflowError，但可能会处理一些任务。 这里的好习惯是什么？

Answer 1

关于捕获Error并因此Throwable没有“良好实践”或“最佳实践” ¹ 。

• 一方面，在某些情况下，JVM可以从某些类型的Error中成功恢复。 例如，如果你在一个单独的线程，不与其他线程（直接或间接）交互运行的“任务”，则该线程可以安全地从一个恢复StackOverflowError并可能² OutOfMemoryError 。

• 另一方面，许多Error子类表明应用程序或JVM处于无法恢复或不可行的状态：

  • 类加载或初始化Error意味着某些类将处于不可用状态。 依赖于类的应用程序将无法继续。
  • 如果使用通知/等待或更高级别同步构造的应用程序在一个线程上获得（比方说） OutOfMemoryError错误，则可能会让其他线程等待可能永远不会到达的通知等。

我的建议是注意javadoc中隐含的Error建议，而不是捕获并尝试从Error或其子类中恢复。 如果您尝试恢复，请考虑应用程序可能“楔入”的可能性。

---

^{1 - 实际上，根本没有“最佳实践”; 请参阅https://www.satisfice.com/blog/archives/5164}

^{2 - 这取决于根本原因。 如果根本原因是代码库中其他地方的内存泄漏，那么恢复是一个坏主意。 OOME很可能会再次出现......频率越来越高。}

Answer 2

这是来自错误的javadoc：

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

我通常遵循此规则以避免抑制应修复的实际意外错误。
你提到StackoverflowError ，如果你有这种错误，你的算法可能有问题，你的代码应该优化。

如果你知道可能会抛出一个特定的错误并且你对此感到满意，你就可以捕获它。 但是，如果你不期望它，最好尽快提高警报并处理它。

Answer 3

好的做法是捕获预定的作业，写关于异常的日志，指标和（可选）重新安排它。

此外，有时您的线程将被停止/销毁（hello spring schedulers）导致您收到某种异常，这对您的工作并不重要......