在Java中使用線程時，處理InterruptedException似乎是我身邊的一個棘手問題。我很欣賞它在我的線程被終止時拋出的事實，因此爲我提供了清理的機會。我覺得奇怪的是，它不是未檢查的異常。爲什麼中斷異常檢查異常？
這就產生了以下問題： 一）如果我想在我的線程應用程序使用現有的框架，我被迫將其轉換爲框架接口接受一個例外。因此，框架通常會曲解它，而不是像它應該清理或傳播它。
b）除非堆棧中每次調用嚴格聲明InterruptedException（並且通常不是因爲a）），否則很難完全關閉。
如果InterruptedException被取消選中，它看起來會有更高的可能性被正確使用，導致線程和應用程序的整體關閉。爲什麼不是？
中斷應該是合作的。我認爲設計師想要避免一種情況，你可以通過中斷它來阻止線程，線程沒有代碼來處理這種可能性。意圖似乎是讓Runnable代碼明確決定如何處理中斷。很多框架或語言代碼似乎都是關於決定應該承擔哪些責任，並試圖明確正確的用法，以最大限度地減少嚴重用戶被燒燬的情況。這是那些判斷要求之一。
由於InterruptedException被檢查，最壞的情況是異常被捕獲，但以一種不太有用的方式。如果未選中，則異常可能會處於未處理狀態，並繼續終止該線程，如果該線程不在停止位置，則該線程可能非常糟糕。
此外，很明顯，設計師傾向於在檢查事項方面犯錯。所以這符合這種趨勢。
我同意中斷是應該是合作的。如果例外情況未被檢查，則會提供「盡力而爲」的折中方案。你可以盡最大努力去合作，或者忽略它，但是無論哪種方式，你將會被關閉，而不是在可能的狀態下繼續運行。 – Andy 2015-02-17 21:46:45
@安迪：會有很好的分數。無論如何，我並不喜歡檢查異常。 – 2015-02-17 22:00:19
我想象一下，在執行多線程解決方案時，決定將此異常檢查與未檢查歸結爲可見性。 「嘿，你應該真的注意這一點，並做好準備。」事情。在編譯時強制執行此操作會迫使實施者至少考慮被中斷的問題。如果不加以控制，將會將這個問題的可見度提高到地平線以下。 – 2015-02-17 21:36:18
投票結束，因爲除了指定它的人之外，我們只能進行有根據的猜測。 – Hannes 2015-02-17 21:38:11
（а）是你的框架問題，而不是'InterruptedException'本身。 （b）'RuntimeException'表示編程錯誤; 'InterruptedException'不是編程錯誤的結果。 – dasblinkenlight 2015-02-17 21:42:31