為什么80%的碼農都做不了架構師？>>> ??

#1. 不需要Checked異常 Java中的Checked異常，可以說有弊無利，它除了能帶來一系列的麻煩，能干的事情Unchecked異常都能干。 ##1.1. 代碼污染 首先，當一個方法聲明拋出一個Checked異常時，該方法的后面就得加上throws XxxException；其次，該方法的調用者必須要處理這種異常：要么繼續拋出，調用方法也得加上throws XxxException；要么捕獲處理，處理方式可能是記錄日志、處理異常流或者再包裝一次拋出去；再次，當方法增加另一個Checked異常時，調用者也必須增加這個異常處理，否者代碼編譯都會出錯。 ##1.2. 調用者未必需要或能夠處理這個異常 Checked異常強調調用者需要處理這種異常，但絕大部分情況是你根本不知道調用者是否真的需要，或者調用者是否有能力去處理這種異常。例如：SQLException，調用者除了能記錄日志或者包裝一下繼續拋出，還能做什么？在程序運行過程中用代碼去修復錯誤的SQL語法嗎？ ##1.3. 都可以用Unchecked異常替代 Checked異常除了強制調用者捕獲處理以外，并不比Unchecked異常能夠攜帶更多信息。舉個常用的例子：用戶登錄，可能輸入錯誤的用戶名或密碼，需要定義兩個異常：UserNotFoundException、PasswordNotMatchException。把這兩個異常定義為Checked異常看上去無可厚非了，調用者顯然是必須也能夠處理這兩個異常的。但反過來想，這兩個異常為什么不能定義為Unchecked異常呢？如果調用者需要分別提示用戶不同的信息，就分別捕獲處理；如果調用者需要統一提示用戶：用戶名或密碼錯誤，就一起捕獲處理；如果調用者本身就有一個頂層統一的異常處理機制呢，就讓它直接拋到頂層去處理好了。聰明的Shiro框架就是這么干的，所有的驗證異常全部都是Unchecked異常。

#2. 不需要太多的異常 通常情況下，應用這個層面的代碼只需要兩種異常：系統異常和業務異常。系統異常用來告訴用戶：系統繁忙，請稍后再試（通常都是這么委婉，實際可能是某個BUG發作了 ^_^）；業務異常，用來告訴用戶具體的業務操作提示信息（新增用戶時，提示用戶名已存在之類的），提示信息放在message屬性里就好了。兩種異常，也就是兩個異常類，它們可以處理掉80%-90%的異常。剩下的情況，只有當需要對某種類型的異常流程進行特殊處理時，才需要增加異常類。例如對外開放API接口時，或許需要定義一個ApiException，用來返回錯誤的消息。

#3. 把異常拋到頂層處理 應用可能分很多層，在頂層設計一個異常處理框架來統一處理異常是明智的選擇。例如三層結構的web應用，應該在表現層統一處理異常，而不是讓異常處理分布在各個層面，像Spring MVC、Struts這些MVC框架都有統一異常處理機制，用好它們就行了。 異常處理往往是開發人員處理不好的一個環節，而這個環節處理又會帶來比較大的麻煩，例如錯誤的處理導致異常中斷了，最終連錯誤日志都找不到。設計好一個頂層異常處理機制，然后告訴開發人員不用處理異常，這樣可以盡可能的避免發生這樣的問題。 正因如此，異常需要透傳到頂層，代碼又需要保持優雅，所以Unchecked異常才是必然的選擇，優秀的開源框架都是這么干的。

轉載于:https://my.oschina.net/jnoee/blog/379980

總結

以上是生活随笔為你收集整理的简化Java中的异常处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。