為什麼例外處理那麼難（5）：流程觀點

May 5 20:12~21:25

 

Process View（流程觀點）

例外處理設計也是軟體開發的一個環節，要能夠被落實就必須要考慮如何把這個環節妥善的「卡入」軟體開發流程當中。無論是waterfall流程也好，敏捷開發方法也罷，當程式設計師遇到例外的時候，心理面總是想著：

I will handle this exception when I have time（當我有空的時候再來處理這個例外）.

很遺憾的，程式設計師永遠都不會有空，因此例外也一直被忽略。看到這邊鄉民們可能會想，不對啊，在敏捷方法中，不是可以用循序漸進的方式，先把一個story區分為normal scenario與failure scenario，然後在這個sprint（開發週期）中先做normal scenario，等告下個sprint再安排時間來做failure scenario這樣搞定了啊。

敏捷開發讓例外處理變得好簡單啊！才怪。

***

以上說法聽起來很有道哩，但實務上問題出在：「做normal scenario的時候遇到例外怎麼辦？」下圖這個fetchRawBytesAndSetupMessage()方法，從DataInputStream得到一個byte array，並且依據規格中定義好的格式把這個byte array的資料設定到Message物件中。

 

在安排story的時候，Product Owner（PO）可以說：「好，我們這個sprint先不用管格式錯誤的問題，先假設byte array的資料一定是正確的，等下個sprint再來處理格式錯誤的問題」。

身為程式設計師的各位鄉民們，並不會因為PO的一句話就讓你在處理normal scenario的情況下不遭遇到例外。上圖中的程式碼就算是在處理normal scenario的情況下，還是會遇到IOException與EOFException，此時程式設計師可能會：

• 啊PO說先不處理，所以就先直接往外丟好了，把IOException宣告在fetchRawBytesAndSetupMessage()的介面上。
• 雖然PO說先不處理，但是宣告在fetchRawBytesAndSetupMessage()介面上只是把例外處理的問題丟給它的呼叫者去煩惱而已，還是應該把例外捕抓下來然後先暫時忽略它比較好。所以把程式寫成下面這樣比較好：

 

• 噯呀，不行啦，忽略例外是一個bad smell，如果不想處理checked exception又不想把它宣告在介面上面，應該改丟出一個runtime exception，請看：

***

敏捷開發法不會讓例外處理變得更簡單。若團隊沒有一套例外處理設計規範，而是依據程式設計師個人的喜好來決定處理方式，則很有可能反而會降低系統的強健度。

***

連續看完這五集「為什麼例外處理那麼難」，最後的結論就是…例外處理真的好難…Orz。

***

友藏內心獨白：終於寫完這五集了。