前言
不管在我們的工作還是生活中，總會出現各種“錯誤”，各種突發的“異常”。無論我們做了多少準備，多少測試，這些異常總會在某個時間點出現，如果處理不當或是不及時，往往還會導致其他新的問題出現。所以我們要時刻注意這些陷阱以及需要一套“最佳實踐”來建立起一個完善的異常處理機制。
正文
異常分類
首先，這裡我畫了一個異常分類的結構圖。
在JDK中，Throwable是所有異常的父類，其下分為”Error“和”Exception“。Error意味著出現了不可控的嚴重錯誤，例如OutOfMemoryError。Exception則細分為兩類，受檢異常（check）需要我們手動try/catch或者在方法定義中throws，編譯器在編譯的時候會檢查其合法性。非受檢異常（uncheck）則不需要我們提前處理。這些簡單的概念對於開發人員來說都是必須掌握的，這裡就展示個圖例，不做詳細的描述了，我們的”正餐“還在後面。
重新認識try/catch/finally
說到異常處理，這裡就不得不提try/catch/finally。try不可以單獨存在，要麼搭配catch，要麼搭配finally，或者三者並存。
1、try程式碼塊：監視程式碼塊的執行，發現對應的的異常則跳轉至catch，若無catch則直接到finally塊。
2、catch程式碼塊：發生對應的異常會執行裡面的程式碼，要麼處理，要麼向上丟擲。
3、finally程式碼塊:不管是否有異常，都必執行，一般用來清理資源，釋放連線等。然而有以下幾種情況不會執行到這裡的程式碼。
- 程式碼執行流程未進入try程式碼塊。
- 程式碼在try程式碼塊中發生死迴圈、死鎖等狀態。
- 在try程式碼塊中執行了System.exit()操作。
try/catch/finally陷阱
下面介紹兩個我們在使用tcf的時候可能會遇到的陷阱。
程式碼1
public class TCFDemo {
public static void main(String[] args) {
//11
System.out.println(returnVal());
}
static int returnVal(){
int a = 1;
int b = 10;
try{
return ++a;
}finally {
return ++b;
}
}
}
複製程式碼陷阱1：在finally中新增return語句，這樣會覆蓋掉try程式碼return的值，假如業務邏輯比較複雜，這裡是很容易掉坑的，不利於排查錯誤。
程式碼2
public class TCFDemo {
public static void main(String[] args) {
Lock lock = new ReentrantLock();
try{
//有可能加鎖失敗
lock.lock();
//dost
}finally {
lock.unlock();
}
}
}
複製程式碼陷阱2：由於lock方法在加鎖的時候有可能會丟擲Uncheck異常，如果在try程式碼塊中，必然會執行unlock方法，此時由於並沒有加鎖成功，所以會丟擲IllegalMonitorStateException，這樣一來後者的異常就覆蓋掉了前者加鎖失敗的異常資訊，所以我們應該把加鎖的方法挪至try程式碼塊外面。
最佳實踐
好了，前面簡單介紹了異常的分類以及try/catch/finally的注意事項，現在可以總結一下我們在異常處理的時候有哪些”最佳實踐“了。
- 當需要向上丟擲異常的時候，需根據當前業務場景定義具有業務含義的異常，優先使用行業內定義的異常或者團隊內部定義好的。例如在使用dubbo進行遠端服務呼叫超時的時候會丟擲DubboTimeoutException，而不是直接把RuntimeException丟擲。
- 請勿在finally程式碼塊中使用return語句，避免返回值的判斷變得複雜。
- 捕獲異常具體的子類，而不是Exception，更不是throwable。這樣會捕獲所有的錯誤，包括JVM丟擲的無法處理的嚴重錯誤。
- 切記更別忽視任何一個異常（catch住了不做任何處理），即使現在能確保不影響邏輯的正常執行，但是對於將來誰都無法保證程式碼會如何改動，別給自己挖坑。
- 不要使用異常當作控制流程來使用，這是一個很奇葩也很影響效能的做法。
- 清理資源，釋放連線等操作一定要放在finally程式碼塊中，防止記憶體洩漏，如果finally塊處理的邏輯比較多且模組化，我們可以封裝成工具方法呼叫，程式碼會比較簡潔。
結尾
小小的異常，有大大的學問，你覺得呢？
