異常處理遇到過的那些坑

今年有個目標之一就是提高團隊代碼的質量，因此時常會思索如何把這件事作到更好，不想教條主義，也不想搞出一個代碼規範，強制團隊照着作，落地的效果很差，反而把你們的積極性給弄沒了。因此個人原則是，咱們一塊兒看看什麼事是咱們不能作的，排除掉，剩下的就是咱們能夠作的，同時真正搞清楚問題在哪裏，而不是簡單的模仿。從我我的的經驗看，代碼優化中最重要的一點就是對異常狀況的處理。今天，我就借這個話題，談談如何來優化咱們的代碼。

坑1：捕捉異常不作處理

以下段代碼所示，不知道各位在自家的代碼中見過多少，我是指望你們不要碰見。且不說printStackTrace()這樣的代碼就不該該出線在正式的上線代碼中，不作處理自己這會致使業務的潛在問題被隱藏了，因此這個坑是我認爲異常處理中最糟糕的一點。

try

{

....

}

catch(Exception ex)
{

ex.printStackTrace();

System.out.println(XXX);

}

對於異常的捕捉處理，遵循如下的流程：

1. 處理該異常，執行具體的邏輯處理，加上必要的系統日誌記錄 （log4j，logcat ...）。

2. 涉及其餘系統或者上一級系統，須要轉換成對應的消息通知相關係統。上一級是前端，須要轉換成前端能夠「讀懂」的錯誤提示。

3. 沒法處理該異常或者該異常須要上一級統一處理，Throw out該異常。

坑2：不處理資源釋放

仍是見代碼說話，若是append出錯，那麼IO流就不會被關掉，那麼最終就會致使整個程序由於溢出崩掉。

FileWriter fileWriter = null;

try

{

fileWriter = new FileWriter("");

fileWriter.append(item.toString());

fileWriter.close();

}

catch (IOException e)

{

...

}

在使用文件、IO流、數據庫鏈接等不會自動釋放的資源時，應該在使用完畢後立刻將其關閉。關閉資源的代碼try...catch...finally的finally內執行，不然就可能由於Exception的緣由形成資源沒法釋放。

坑3：對異常不進行分類處理

代碼中，最容易看到的一種狀況就是設定catch的異常類型是Exception, 而且只有一套處理邏輯, 以下：

try{

...

}

catch (Exception e){

...

}

這裏的問題主要有如下兩點：

1. catch的不一樣Exception，可能須要執行不一樣的處理邏輯，一個catch要同時處理全部邏輯就很難實現。

2. 因爲是捕捉的基類Exception, 那麼RuntimeException也會被捕捉到，若是稍微不注意的話，RuntimeException最終沒有任何實際處理，代碼中的真正錯誤被掩蓋掉了。

因此，正確的作法應該是按照具體的異常進行分類處理, 例如：

try{

...

}

catch (FileNotFoundException e){

// alert that the specified file

// does not exist

}

catch (EOFException e){

// alert that the end of the file

// was reached

}

catch (ObjectStreamException e){

// alert that the file is corrupted

}

catch (IOException e){

// alert that some other I/O

// error occurred

}

坑4：將大段代碼放進一個Try-Catch中

　　有時能夠看到，一些代碼的做者巴不得把整個函數裏的實現代碼都放入單個try中，緣由就在於爲了圖省事，不肯花時間分析一大塊代碼中哪幾行代碼會拋出什麼異常、異常的具體類型是什麼，應該如何處理。這樣的作法致使異常發生後，後續調試找問題更麻煩，一大段代碼中有太多的地方可能拋出Exception。這樣的作法致使，很難去統計和判斷要catch哪一些類型的Exception, 只能寫一個粗糙的Exception, 又掉進咱們說的第3個坑裏。

一點總結

在和你們一塊兒分析了上面的異常坑後，若是將來咱們想避免踩進一個異常坑，編寫異常代碼能夠遵循如下三個點：

1. 出了什麼錯?

2. 在哪出的錯?

3. 爲何出錯?

掃描二維碼或手動搜索微信公衆號【架構棧】： ForestNotes

歡迎轉載，帶上如下二維碼便可