Java異常處理最佳實踐及陷阱防範

前言

無論在咱們的工做仍是生活中，總會出現各類「錯誤」，各類突發的「異常」。不管咱們作了多少準備，多少測試，這些異常總會在某個時間點出現，若是處理不當或是不及時，每每還會致使其餘新的問題出現。因此咱們要時刻注意這些陷阱以及須要一套「最佳實踐」來創建起一個完善的異常處理機制。

正文

異常分類

首先，這裏我畫了一個異常分類的結構圖。

在JDK中，Throwable是全部異常的父類，其下分爲」Error「和」Exception「。Error意味着出現了不可控的嚴重錯誤，例如OutOfMemoryError。Exception則細分爲兩類，受檢異常（check）須要咱們手動try/catch或者在方法定義中throws，編譯器在編譯的時候會檢查其合法性。非受檢異常（uncheck）則不須要咱們提早處理。這些簡單的概念對於開發人員來講都是必須掌握的，這裏就展現個圖例，不作詳細的描述了，咱們的」正餐「還在後面。

從新認識try/catch/finally

說到異常處理，這裏就不得不提try/catch/finally。try不能夠單獨存在，要麼搭配catch，要麼搭配finally，或者三者並存。
一、try代碼塊：監視代碼塊的執行，發現對應的的異常則跳轉至catch，若無catch則直接到finally塊。
二、catch代碼塊：發生對應的異常會執行裏面的代碼，要麼處理，要麼向上拋出。
三、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的注意事項，如今能夠總結一下咱們在異常處理的時候有哪些」最佳實踐「了。

1. 當須要向上拋出異常的時候，需根據當前業務場景定義具備業務含義的異常，優先使用行業內定義的異常或者團隊內部定義好的。例如在使用dubbo進行遠程服務調用超時的時候會拋出DubboTimeoutException，而不是直接把RuntimeException拋出。
2. 請勿在finally代碼塊中使用return語句，避免返回值的判斷變得複雜。
3. 捕獲異常具體的子類，而不是Exception，更不是throwable。這樣會捕獲全部的錯誤，包括JVM拋出的沒法處理的嚴重錯誤。
4. 切記更別忽視任何一個異常（catch住了不作任何處理），即便如今能確保不影響邏輯的正常運行，可是對於未來誰都沒法保證代碼會如何改動，別給本身挖坑。
5. 不要使用異常看成控制流程來使用，這是一個很奇葩也很影響性能的作法。
6. 清理資源，釋放鏈接等操做必定要放在finally代碼塊中，防止內存泄漏，若是finally塊處理的邏輯比較多且模塊化，咱們能夠封裝成工具方法調用，代碼會比較簡潔。

結尾

小小的異常，有大大的學問，你以爲呢？

公衆號《深夜裏的程序猿》 - 分享最乾的乾貨