Java異常處理12條軍規

https://mp.weixin.qq.com/s/Oo53o8Qhiu8VHH70dTIOuA

在Java語言中,異常從使用方式上可以分爲兩大類:

  • CheckedException

  • UncheckedException

在Java中類的異常結構圖如下:

  1. 可檢查異常需要在方法上聲明,一般要求調用者必須感知異常可能發生,並且對可能發生的異常進行處理。可以理解成系統正常狀態下很可能發生的情況,通常發生在通過網絡調用外部系統或者使用文件系統時,在這種情況下,錯誤是可能恢復的,調用者可以根據異常做出必要的處理,例如重試或者資源清理等。

  2. 非檢查異常是不需要在throws子句中聲明的異常。JVM根本不會強制您處理它們,因爲它們主要是由於程序錯誤而在運行時生成的。它們擴展了RuntimeException。最常見的例子是NullPointerException 可能不應該重試未經檢查的異常,並且正確的操作通常應該是什麼都不做,並讓它從您的方法和執行堆棧中出來。在高執行級別,應記錄此類異常。

  3. Error是最爲嚴重的運行時錯誤,幾乎是不可能恢復和處理,一些示例是OutOfMemoryError,LinkageError和StackOverflowError。它們通常會使程序或程序的一部分崩潰。只有良好的日誌記錄練習才能幫助您確定錯誤的確切原因.

 

在異常處理時的幾點建議:

 

1永遠不要catch中吞掉異常,否則在系統發生錯誤時,你永遠不知道到底發生了什麼

  •  
  •  
  •  
catch (SomeException e) {  return  null;}

2儘量使用特定的異常而不是一律使用Exception這樣太泛泛的異常

  •  
public void foo() throws Exception { //錯誤的做法}
  •  
public void foo() throws MyBusinessException1, MyBusinessException2 { //正確的做法}

        一味的使用Exception,這樣就違背了可檢查異常的設計初衷,因爲調用都不知道Exception到底是什麼,也不知道該如何處理。捕獲異常時,也不要捕獲範圍太大,例如捕獲Exception,相反,只捕獲你能處理的異常,應該處理的異常。即然方法的聲明者在方法上聲明瞭不同類型的可檢查異常,他是希望調用者區別對待不同異常的。

3Never catch Throwable class

    永遠不要捕獲Throwable,因爲Error也是繼承自它,Error是Jvm都處理不了的錯誤,你能處理?所以基於有些Jvm在Error時就不會讓你catch住。

4正確的封裝和傳遞異常

不要丟失異常棧,因爲異常棧對於定位原始錯誤很關鍵

  •  
  •  
  •  
catch (SomeException e) {throw  new MyServiceException("Some information: " + e.getMessage());  //錯誤的做法}

一定要保留原始的異常:

  •  
  •  
  •  
catch (SomeException e) {   throw new MyServiceException("Some information: " , e);  //正確的打開方式}

 

5要打印異常,就不要拋出,不要兩者都做

  •  
  •  
  •  
  •  
catch (SomeException e) {   LOGGER.error("Some information", e);throw e;}

這樣的log沒有任何意義,只會打印出一連串的error log,對於定位問題無濟於事。

 

6不要在finally塊中拋出異常

如果在finally中拋出異常,將會覆蓋原始的異常,如果finally中真的可能會發生異常,那一定要處理並記錄它,不要向上拋。

 

7不要使用printStackTrace

要給異常添加上有用的上下文信息,單純的異常棧,沒有太大意義

 

8Throw early catch late

異常界著名的原則,錯誤發生時及早拋出,然後在獲得所以全部信息時再捕獲處理.也可以理解爲在低層次拋出的異常,在足夠高的抽象層面才能更好的理解異常,然後捕獲處理。

 

9對於使用一些重量級資源的操作,發生異常時,一定記得清理

如網絡連接,數據庫操作等,可以用try finally來做clean up的工作。

 

10不要使用異常來控制程序邏輯流程

我們總是不經意間這麼做了,這樣使得代碼變更醜陋,使得正常業務邏輯和錯誤處理混淆不清;而且也可能會帶來性能問題,因爲異常是個比較重的操作。

 

11及早校驗用戶的輸入

在最邊緣的入口校驗用戶的輸入,這樣使得我們不用再更底層邏輯中處處校驗參數的合法性,能大大簡化業務邏輯中不必要的異常處理邏輯;相反,在業務中不如果擔心參數的合法性,則應該使用衛語句拋出運行時異常,一步步把對參數錯誤的處理推到系統的邊緣,保持系統內部的清潔。

 

12在打印錯誤的log中儘量在一行中包含儘可能多的上下文

 

  •  
  •  
LOGGER.debug("enter A");LOGGER.debug("enter B"); //錯誤的方式
  •  
LOGGER.debug("enter A, enter B");//正確的方式

Thanks all. Happy Learning!!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章