在調度程序中捕獲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）導致您收到某種異常，這對您的工作並不重要......