視力測驗：例外處理篇（1）

Feb. 04 09:42~10:05

 

Kay建議Teddy在《笑談軟體工程：例外處理設計的逆襲》這本書裡面加上一章，出幾道問題讓讀者們自我評量一下對於例外處理的了解程度。昨天花了點時間出了12道題目，打算放到新書裡面當作第一章。

這種「問題導向學習方法」，對於在台灣從小考到大的鄉民們應該很熟悉。在部落格上面寫了不少例外處理的文章，這一系列的文章就改以考題的方式來呈現。前兩集先把昨天出好的12題「洩題」給鄉民們參考，答案在書的附錄A，書預計3月下旬出版。

有興趣作答的鄉民可以留言。計時6分鐘，請開始作答。

***

1. 關於例外處理的敘述，何者是錯的？

A. 例外處理是一種非功能需求（non-functional requirement）。

B. 妥善的例外處理可以提高系統強健度（robustness）。

C. 因為及時上市（time-to-market）的原因，有時候就算知道產品的例外處理設計不完善，還是只能釋出讓客戶先使用，事後再想辦法慢慢修正。

D. 所有的例外狀況在需求分析時都可以被找出來。

E. 以上皆非。

2.  以下那種狀況應該交由例外處理來對付，才不至於需要付出容錯設計的高額成本？

A. NullPointerException或NullReferenceException。

B. 陣列索引超出範圍。

C. 硬碟空間不足。

D. 以上皆是。

E. 以上皆非。

3. 在finally block裡面發生例外，採取何種做法比較洽當？

A. 把例外往外丟。

B. 捕捉起來然後忽略它。

C. 捕捉起來然後印在主控台（console）。

D. 捕捉起來然後寫到日誌檔中。

E. 以上皆可。

4. C#與Objective-C的例外類別因為實作了以下哪一個模式（pattern），可以讓例外物件夾帶不固定數量的使用者自訂資料？

A. Collecting Parameter。

B. Variable State。

C. Composite。

D. Strategy。

E. State。

5. 敏捷開發讓例外處理設計變得…

A. 更簡單，因為不需要做太多事前設計（up-front design），所以不用考慮太多情況就可以寫動手程式。

B. 更難，因為不允許做太多事前設計，而且需求改來改去，造成例外處理更難設計。

C. 沒差別，因為不管用什麼開發方法，我們從來都沒花時間去設計例外處理。

D. 更難，因為每天都要開會討論例外處理的問題。

E. 更簡單，因為開發人員會自我管理，所以不需要擔心例外處理設計的問題。

6. Fault、error、failure在例外處理設計中經常會聽到的三個名詞。以下關於這三者的敘述何者為對？

A. Failure表示程式設計錯誤（programming error）。

B. Error表示一個函數無法如其規格所描述，提供正確的服務。

C. Fault表示系統處於不正確的狀態。

D. 以上皆非。

E. 以上皆是。

***

友藏內心獨白：這是視力測驗，不是智力測驗。