l

2013年5月6日 星期一

為什麼例外處理那麼難(5):流程觀點

May 5 20:12~21:25

image

 

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物件中。

螢幕快照 2013-05-05 下午9.12.28

 

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

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

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

螢幕快照 2013-05-05 下午9.13.35

 

  • 噯呀,不行啦,忽略例外是一個bad smell,如果不想處理checked exception又不想把它宣告在介面上面,應該改丟出一個runtime exception,請看:
螢幕快照 2013-05-05 下午9.15.27

***

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

***

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

***

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

沒有留言:

張貼留言