為什麼例外處理那麼難（3）：處理觀點

Apr. 29 21:14~22:26

 

Handling View（處理觀點）

從第2集的「設計觀點」鄉民可以得知一個元件是否會丟出例外（declared或是undeclared例外），再利用第1集的「使用觀點」來判斷這個例外是否真的代表failure或只是狀態通知。如果是代表failure，就可以準備著手來設計處理例外的方法。

處理觀點關注下列兩個因素：

• Recoverability (可恢復性)
• recoverable或unrecoverable(irrecoverable)
• Exception handling constructs in languages and utilities
• Roles, responsibilities, and collaborations (e.g., try, catch, finally in Java)
  

先談談recoverability。一個例外狀況可不可修、要不要修，要同時考量callee與caller的情況(callee的狀態是否正確，caller是否有足夠的context來處理)。回顧一下Teddy在第1集裡面提到的例子，InterruptedException要怎麼處理？首先，這個例外的本質是一種狀態通知，並非代表failure。其次，在sleepMillisecond()這個context底下，當InterruptedException發生時，還是代表狀態通知，而且系統中沒有什麼狀態需要被恢復，所以針對這個例外的處理方法就是捕捉到例外之後直接離開這個method就功德圓滿了。

***

接下來討論一下exception handling constructs in languages and utilities。既然談到設計觀點，最後就必須要考慮設計要如何被實作的問題，此時就牽扯到程式語言對於例外處理的支援，以及是否有例外處理utilities可以使用。

不同的程式語言有著不同的例外處理構件，鄉民們必須要充分理解，才不會設計出錯誤的例外處理程式（很多系統的bug其實是發生在例外處理程式碼之中）。

鄉民甲：這個簡單啊，我Java用了那麼多年了，try-catch-finally熟的很。

Teddy：既然你那麼熟，可以談一下catch的責任嗎？

鄉民甲：catch就是把例外抓起來啊，然後作例外處理。

Teddy：可以說的再精確一點嗎？

鄉民甲：已經很精確了啊，不然你是要怎樣啦！

Teddy：看一下下面這張投影片，思考一下你對於try-catch-finally的理解和Teddy的理解是否一樣。

***

要判斷一個例外是否為一個可修復的狀況，是例外「處理」的第一個步驟，但是這個判斷並不是一件容易的事。確定了例外的recoverability之後，接著可利用程式語言構件與軟體元件的協助來實作例外處理程式碼。

***

友藏內心獨白：用力讀，讀懂就賺到了。