例外處理壞味道：將例外當作控制流程

April 21 01:33~14:12

 

在〈例外處理壞味道（上）〉與〈例外處理壞味道（下）〉Teddy介紹了以下幾種例外處理壞味道（exception handling bad smells）：

• Return Code（回傳碼）
• Ignored Checked Exception（忽略受檢例外）
• Ignored Exception（忽略例外）
• Unprotected Main Program（未被保護的主程式）
• Dummy Handler（虛設的處理者）
• Nested Try Statement（巢狀Try敘述）
• Spare Handler（備胎）
• Careless Cleanup（粗心的資源釋放）

昨天在北科上課review學生的作業，看到另一個很常見的例外處理壞味道：將例外當作控制流程（using exceptions as control flow）。

***

▼下圖是學生所寫的程式碼示意圖，getCompanyName函數首先判斷參數obj是否包含錯誤，如果是則丟出一個Exception並將其內容設為「找不到資料」。在第39行的catch clause中捕捉例外，然後傳回例外物件的getMessage字串。

 

問題一

有經驗的鄉民一眼就可以看出來上面這段程式出了什麼問題，首先在第29行丟出例外然後在第41行捕捉例外這種寫法就是典型的將例外作為控制流程，和寫go to是類似的效果。

▼程式可以改成當判斷obj物件包含錯誤的時候，直接傳回 “找不到資料”這個字串就可以了。

 

問題二

原本的程式寫法直接捕捉exception物件，這個物件在Java例外物件的階層中僅次於Throwable，捕捉Throwable或Exception這種寫法叫做blanket catch（請參考〈Java的try、catch、finally（1）：Java SE 7之前〉）。在原本的程式碼中27~39行的try clause除了29行以外其他地方也可能會丟出例外，所以就算原本的程式碼不介意使用例外作為控制流程，41~43行的例外處理程式（exception handler）也可能因為其他程式發生例外而被觸發。也就是說，當呼叫getCompanyName函數的人收到"找不到資料"這個字串的時候，在原本的寫法當中有可能因為兩個原因所造成：

• 真的找不到資料。
• 因為發生例外被誤判為找不到資料。

很顯然地原本的程式邏輯是不正確的。

***

在絕大部分的情況下，例外應該單純用在程式異常狀況，而非因為丟出例外可以具有流程控制的特性而將例外使用在流程控制上。對於例外處理設計有興趣的鄉民們可以參考泰迪軟體的「例外處理設計與重構實作班」課程，或是Teddy所寫的《笑談軟體工程：例外處理設計的逆襲》 。

***

友藏內心獨白：程式不是看起來可以動就沒事了。