為什麼例外處理那麼難（2）：設計觀點

Apr. 29 16:40~17:42

上一集提到例外使用觀點，今天介紹例外處理的設計觀點。

***

Design View（設計觀點）

今天早上看到一則新聞，大意是說對岸駭客可能會將入侵目標轉向台灣，對台灣國防、政治、經濟安全造成危害。記者電話訪問了某警察單位…

記者：對於對岸駭客可能會入侵台灣一事警察單位有什麼因應之道？

警察：我們主要還是要看有沒有人報案，有人報案我們就會處理。

Teddy內心獨白：靠…過一來點…「有人報案我們就會處理」這是哪招，會不會太消極了一點？

***

專案經理：對於我們產品品質不佳，bug很多一事團隊有何因應之道？

程式設計師：我們主要還是要看有沒有人報案回報bug，有人回報我們就會處理。

Teddy內心獨白：以上對話好像在那裡聽過。

***

以上對話和例外處理有何關係？對於例外處理的看法，其實開發人員和警察杯杯的想法很像：「只要有人報案，我們就會處理」。在程式中要如何「報案」？很簡單，就是回報一個例外。從設計（compile-time）的角度來看，例外的回報有以下兩種形式：

• Declared:
• 例外有宣告在元件的介面規範中
• 又稱為anticipated或expected例外
• 代表component fault
• Undeclared:
• 例外沒有宣告在元件的介面規範中
• 又稱為unanticipated或unexpected例外
• 代表design fault
  

看一個例子Java程式例子。IllegalArgumentException在下圖上方的程式碼中是屬於undeclared exception，因為它沒有被宣告在deposit()介面上面。反之，下方程式碼的IllegalArgumentException是屬於declared exception，理由當然是它有被宣告在deposit()介面上。

***

就好像如果沒有人報案警察不知如何因應是一樣的道理，唯有將例外宣告在介面上(或以某種形式存在程式或文件中)，在設計階段程式設計師才有機會知道要如何來因應可能會遭遇到的異常狀況。嚴格來講，要求開發人員去處理undeclared例外，已非例外處理的範疇，而是屬於「容錯設計」的議題，這比例外處理要困難許多。

***

友藏內心獨白：區分例外處理和容錯設計是有意義的。