關於在 Java 語言中使用異常的大多數建議都認為，在確信異常可以被捕捉的任何情況下，應該優先使用檢查型異常。語言設計（編譯器強制您在方法簽名中列出可能被拋出的所有檢查型異常）以及早期關於樣式和用法的著作都支持該建議。最近，幾位聞名的作者已經開始認為非檢查型異常在優秀的 Java 類設計中有著比以前所認為的更為重要的地位。在本文中，Brian Goetz 考察了關於使用非檢查型異常的優缺點。
與 C++ 類似，Java 語言也提供異常的拋出和捕捉。但是，與 C++ 不一樣的是，Java 語言支持檢查型和非檢查型異常。Java 類必須在方法簽名中聲明它們所拋出的任何檢查型異常，並且對於任何方法，假如它調用的方法拋出一個類型為 E 的檢查型異常，那麼它必須捕捉 E 或者也聲明為拋出 E（或者 E 的一個父類）。通過這種方式，該語言強制我們文檔化控制可能退出一個方法的所有預期方式。
對於因為編程錯誤而導致的異常，或者是不能期望程序捕捉的異常（解除引用一個空指針，數組越界，除零，等等），為了使開發人員免於處理這些異常，一些異常被命名為非檢查型異常（即那些繼續自 RuntimeException 的異常）並且不需要進行聲明。
傳統的觀點
在下面的來自 Sun 的“The Java Tutorial”的摘錄中，總結了關於將一個異常聲明為檢查型還是非檢查型的傳統觀點（更多的信息請參閱 參考資料）：
因為 Java 語言並不要求方法捕捉或者指定運行時異常，因此編寫只拋出運行時異常的代碼或者使得他們的所有異常子類都繼續自 RuntimeException ，對於程序員來說是有吸引力的。這些編程捷徑都答應程序員編寫 Java 代碼而不會受到來自編譯器的所有挑剔性錯誤的干擾，並且不用去指定或者捕捉任何異常。盡管對於程序員來說這似乎比較方便，但是它回避了 Java 的捕捉或者指定要求的意圖，並且對於那些使用您提供的類的程序員可能會導致問題。
檢查型異常代表關於一個合法指定的請求的操作的有用信息，調用者可能已經對該操作沒有控制，並且調用者需要得到有關的通知 —— 例如，文件系統已滿，或者遠端已經關閉連接，或者訪問權限不答應該動作。
假如您僅僅是因為不想指定異常而拋出一個 RuntimeException，或者創建 RuntimeException 的一個子類，那麼您換取到了什麼呢？您只是獲得了拋出一個異常而不用您指定這樣做的能力。換句話說，這是一種用於避免文檔化方法所能拋出的異常的方式。在什麼時候這是有益的？也就是說，在什麼時候避免注明一個方法的行為是有益的？答案是“幾乎從不。”
換句話說，Sun 告訴我們檢查型異常應該是准則。該教程通過多種方式繼續說明，通常應該拋出異常，而不是 RuntimeException —— 除非您是 JVM。
在 Effective Java: Programming Language Guide 一書中，Josh Bloch 提供了下列關於檢查型和非檢查型異常的知識點，這些與 “The Java Tutorial” 中的建議相一致（但是並不完全嚴格一致）：
第 39 條：只為異常條件使用異常。也就是說，不要為控制流使用異常，比如，在調用 Iterator.next() 時而不是在第一次檢查 Iterator.hasNext() 時捕捉 NoSUChElementException。
第 40 條：為可恢復的條件使用檢查型異常，為編程錯誤使用運行時異常。這裡，Bloch 回應傳統的 Sun 觀點 —— 運行時異常應該只是用於指示編程錯誤，例如違反前置條件。
第 41 條：避免不必要的使用檢查型異常。換句話說，對於調用者不可能從其中恢復的情形，或者惟一可以預見的響應將是程序退出，則不要使用檢查型異常。
第 43 條：拋出與抽象相適應的異常。換句話說，一個方法所拋出的異常應該在一個抽象層次上定義，該抽象層次與該方法做什麼相一致，而不一定與方法的底層實現細節相一致。例如，一個從文件、數據庫或者 JNDI 裝載資源的方法在不能找到資源時，應該拋出某種 ResourceNotFound 異常（通常使用異常鏈來保存隱含的原因），而不是更底層的 IOException、SQLException 或者 NamingException。
重新考察非檢查型異常的正統觀點
最近，幾位受尊敬的專家，包括 Bruce Eckel 和 Rod Johnson，已經公開聲明盡管他們最初完全同意檢查型異常的正統觀點，但是他們已經認定排他性使用檢查型異常的想法並沒有最初看起來那樣好，並且對於許多大型項目，檢查型異常已經成為一個重要的問題來源。Eckel 提出了一個更為極端的觀點，建議所有的異常應該是非檢查型的；Johnson 的觀點要保守一些，但是仍然暗示傳統的優先選擇檢查型異常是過分的。（值得一提的是，C# 的設計師在語言設計中選擇忽略檢查型異常，使得所有異常都是非檢查型的，因而幾乎可以肯定他們具有豐富的 Java 技術使用經驗。但是，後來他們的確為檢查型異常的實現留出了空間。）
對於檢查型異常的一些批評
Eckel 和 Johnson 都指出了一個關於檢查型異常的相似的問題清單；一些是檢查型異常的內在屬性，一些是檢查型異常在 Java 語言中的特定實現的屬性，還有一些只是簡單的觀察，主要是關於檢查型異常的廣泛的錯誤使用是如何變為一個嚴重的問題，從而導致該機制可能需要被重新考慮。
檢查型異常不適當地暴露實現細節
您已經有多少次看見（或者編寫）一個拋出 SQLException 或者 IOException 的方法，即使它看起來與數據庫或者文件毫無關系呢？對於開發人員來說，在一個方法的最初實現中總結出可能拋出的所有異常並且將它們增加到方法的 throws 子句（許多 IDE 甚至幫助您執行該任務）是十分常見的。這種直接方法的一個問題是它違反了 Bloch 的 第 43 條 —— 被拋出的異常所位於的抽象層次與拋出它們的方法不一致。
