April 20 11:28~12:45
Teddy在2012與2014年所出版的兩本書《笑談軟體工程：敏捷開發法的逆襲》與《笑談軟體工程：例外處理設計的逆襲》已經絕版一陣子了。上個周末上【Scrum敏捷方法實作班】，有學員知道書已絕版，詢問Teddy是否能提供第一本書的電子檔？Teddy也忘了之前有沒有公開提供過，所以今天就寫一篇文章把這兩本書的電子檔公開。
因為書本最後出版的格式經過悅知出版社編輯過，這個「排版編輯」版權屬於出版社，所以Teddy只能公開當初提供給出版社的原稿。編輯前的原稿與最後出版的內容略有差異，且可能有一些尚未訂正的錯字，請讀者自行除錯。
電子檔下載：
***
友藏內心獨白：紙本的比較香。
April 21 01:33~14:12
在〈例外處理壞味道（上）〉與〈例外處理壞味道（下）〉Teddy介紹了以下幾種例外處理壞味道（exception handling bad smells）：
昨天在北科上課review學生的作業，看到另一個很常見的例外處理壞味道：將例外當作控制流程（using exceptions as control flow）。
***
▼下圖是學生所寫的程式碼示意圖，getCompanyName函數首先判斷參數obj是否包含錯誤，如果是則丟出一個Exception並將其內容設為「找不到資料」。在第39行的catch clause中捕捉例外，然後傳回例外物件的getMessage字串。
問題一
有經驗的鄉民一眼就可以看出來上面這段程式出了什麼問題，首先在第29行丟出例外然後在第41行捕捉例外這種寫法就是典型的將例外作為控制流程，和寫go to是類似的效果。
▼程式可以改成當判斷obj物件包含錯誤的時候，直接傳回 “找不到資料”這個字串就可以了。
問題二
原本的程式寫法直接捕捉exception物件，這個物件在Java例外物件的階層中僅次於Throwable，捕捉Throwable或Exception這種寫法叫做blanket catch（請參考〈Java的try、catch、finally（1）：Java SE 7之前〉）。在原本的程式碼中27~39行的try clause除了29行以外其他地方也可能會丟出例外，所以就算原本的程式碼不介意使用例外作為控制流程，41~43行的例外處理程式（exception handler）也可能因為其他程式發生例外而被觸發。也就是說，當呼叫getCompanyName函數的人收到"找不到資料"這個字串的時候，在原本的寫法當中有可能因為兩個原因所造成：
很顯然地原本的程式邏輯是不正確的。
***
在絕大部分的情況下，例外應該單純用在程式異常狀況，而非因為丟出例外可以具有流程控制的特性而將例外使用在流程控制上。對於例外處理設計有興趣的鄉民們可以參考泰迪軟體的「例外處理設計與重構實作班」課程，或是Teddy所寫的《笑談軟體工程：例外處理設計的逆襲》 。
***
友藏內心獨白：程式不是看起來可以動就沒事了。
March 31 07:40~08:16
▲看到這樣的網路銀行畫面用起來心裡會不會毛毛地？
有一句閩南語俗話是這樣說的：「生吃都不夠，哪還有多的可以曬乾？」這句話很確切的點出例外處理的處境—「開發正常功能的時間都不夠，哪還有多餘的時間去處理例外狀況？」
沒有多餘的食物拿來曬乾不打緊，但軟體系統沒有好好地處理例外狀況卻是很嚴重的問題。不穩定的系統輕則無法提供正常服務給使用者，重則造成使用者時間、金錢甚至是生命安全的危害。在強調使用者體驗的今日，系統穩定度不良的問題，絕對不是請使用者重開機或是不斷地重新載入（reload）網頁就可以輕鬆帶過。
▲Facebook錯誤畫面，大拇指受傷比讚就不好看了啊XD
***
身為專業軟體開發人員的各位鄉民，從小到大一定學過各式各樣的軟體設計技術與方法。從最基礎的程式語言、資料結構與演算法，到物件導向分析與設計、設計模式、軟體架構，以及各種敏捷開發實務做法，包含自動化測試、測試驅動開發、行為驅動開發、持續整合、敏捷設計原則等。以上，所有的大師費盡一生心力，都在告訴各位一件事：「如何設計軟體的光明面，也就是『正常行為』（normal behavior）」。而Teddy要告訴鄉民們，如何對付軟體的黑暗面，也就是『異常行為』（abnormal behavior）。唯有正常與異常的行為「陰陽調和」，軟體才可以提供正常且穩定的服務給客戶。
***
【例外處理設計與重構實作班】專治例外處理疑難雜症，適合以下人士：
***
課程介紹與報名網址在此【看板方法與精實開發實作班】，上課日期2017年5月2、3日（二、三）。
***
友藏內心獨白：想成為絕地武士須先克服黑暗力量。
July 20 23:10~00:00
在《星際大戰》電影中，安納金·天行者是一位擁有強大原力的絕地武士，但因為無法抗拒原力黑暗面的力量，最終投入西斯大帝陣營，變成惡名昭彰的黑武士，活在痛苦之中。
軟體和原力一樣，有光明面與黑暗面。從小到大鄉民們所學的各式各樣軟體設計技術與方法，從最基本的程式語言、資料結構與演算法，到物件導向分析與設計、設計模式、軟體架構，以及各種敏捷開發實務做法，包含自動化測試、測試驅動開發、行為驅動開發、持續整合、敏捷設計原則等。以上所有方法都在告訴你一件事：「如何設計軟體的光明面，也就是「正常行為」。而Teddy要告訴鄉民們，如何對付軟體的黑暗面—也就是「異常行為」。唯有面對黑暗面並控制對黑暗的渴望與恐懼，宇宙 軟體系統才可以獲得平衡，
***
你的軟體是否正遭遇以下問題：
歡迎報名參加「例外處理設計與重構實作班」，專治上述疑難雜症。課程內容包含：
上課日期9月2、3日（五、六） 9:30-16:30，兩天共12小時。
***
友藏內心獨白：異常行為的暗黑力量不可以忽視。
May 16 11:10~11:50
▲把這一本看完、看懂，就已經很厲害了
有鄉民在〈美好的事物〉留言問到：「例外處理還有什麼可以參考的呢？」從實務觀點來看，能夠把《笑談軟體工程：例外處理設計的逆襲》讀完、讀懂，應該就很夠用了。如果還想進一步專研，Teddy提供當年博士論文參考資料清單給鄉民們參考，藍色部分為優先建議閱讀資料。
***
[1] K. Arnold, J. Gosling, and D. Holmes, The Java Programming Language, 4th ed., Addison-Wesley, 2006.
[5] B. Eckel, Thinking in Java, 4th ed., Prentice Hall, 2006, pp. 477-478.
[6] P. A. Lee and T. Anderson, Fault Tolerance: Principles and Practice, 2nd ed., Wien, 1990.
[9] J. L. Knudsen, “Exception Handling versus Fault Tolerance,” Proc. of ECOOP’00, Springer-Verlag, 2001, pp. 1-17.
[10] S. Stelting, Robust Java: Exception Handling, Testing and Debugging, Prentice Hall PTR, 2005.
[12] J. Bloch, Effective Java Programming Language Guide, Addison Wesley, 2001.
[13] B. Stroustrup, The C++ Programming Language, 3rd ed., Addison-Wesley, 2000.
[14] J. Shore, “Fail fast,” IEEE Software, 21 (5), 2004, pp. 21-25.
[15] P. A. Lee and T. Anderson, Fault Tolerance: Principles and Practice, 2nd ed., 1990, Springer.
[16] L. L. Pullum, Software Fault Tolerance Techniques and Implementation, Artech House, 2001.
[18] B. Myer, Object-Oriented Software Construction, 2nd ed., Prentice Hall, 1997.
[19] R. Wirfs-Brock, “Designing for recovery,” IEEE Software, 23 (4), 2006, pp. 11-13.
[20] A. Müller and G. Simmons, “Exception Handling: Common Problems and Best Practice with Java 1.4,” Net.ObjectDays 2002, 2002, Last checked on 2008-6-12, <http://www.old.netobjectdays.org/node02/de/Conf/publish/slides.html>.
[22] W. Pree, Design Patterns for Object-Oriented Software Development, Addison Wesley, 1995, pp.98-99.
[24] T. Archer and A. Whitechapel, Inside C#, 2nd ed., Microsoft Press, 2002.
[25] S. Northover and M. Wilson, SWT: The Standard Widget Toolkit, Volume 1, Addison-Wesley, 2004.
[28] A. Haase, “Java idioms: exception handling,” EuroPLoP’2002, 2002.
[29] M. Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000.
[31] B. V. Haecke, JDBC 3.0: Java Database Connectivity, M&T Books, 2002.
[34] M. Parsian, JDBC Recipes: A Problem-Solution Approach, Apress, 2005.
[35] J. Bloch and N. Gafter, Java Puzzlers: Traps, Pitfalls, and Corner Cases, Addison-Wesley, 2005.
[36] K. Beck, Smalltalk Best Practice Patterns, Prentice Hall, 1996.
[39] MSDN, .NET Framework Class Library: Exception.Data Property, Last checked on 2008-08-12, <http://msdn.microsoft.com/en-us/library/system.exception.data(VS.80).aspx>.
[41] K. Renzel, “Error handling, a pattern language,” 1997, Last checked on 2007-07-24, <http://www.objectarchitects.de/arcus/cookbook/exhandling/index.htm>.
[42] D. Schwarz, “Avoiding checked exceptions,” 2004, Last checked on 2007-07-24, <http://www.oreillynet.com/onjava/blog/2004/09/avoiding_checked_exceptions.html>
[43] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel, A Pattern Language, Oxford University Press, 1977.
[44] C. Alexander, The Timeless Way of Building, Oxford University Press, 1979.
[51] A. S. Tanenbaum and M. V. Steen, Distributed Systems: Principles and Paradigms, Prentice Hall, 2002.
[53] G. Meszaros, xUnit Test Patterns: Refactoring Test Code, Addison-Wesley, 2007.
[54] J. Kerievsky, Refactoring to Patterns, Addison-Wesley, 2006.
[55] M. Lippert, and S. Roock, Refactoring in Large Software Projects: Performing Complex Restructurings Successfully, Wiley, 2006.
[61] R. Laddad, “Aspect-Oriented Refactoring, parts 1 and 2,” The Server Side, 2003, Last checked on 2007-10-12. < http://www.theserverside.com/>.
[62] A. Longshaw and E. Woods, “More patterns for the generation, handling and management of errors,” EuroPLOP’2005, 2005.
***
畢業已多年想必這些年陸續有許多新的參考資料不在上面這個清單之中，鄉民們可以用以下關鍵字去Google搜尋或是找學術期刊：
***
友藏內心獨白：沒事看麼多書幹嘛XD。
Dec. 14 14:18~15:20
▲例外處理設計local context程式範例
11月底到某校資工系介紹3小時的例外處理，提早10分鐘到教室準備設定環境。門口有一位學生要Teddy在點名單上「簽到」，很高興他將Teddy誤認為「大二學生」，真的很給面子XD。
上課時間一到，只有約一半的學生準時出席。早上9:10的課有一半的學生能夠準時出席已經不錯了，在台灣的大學應該算是很普遍的現象。
這3個小時的內容是從泰迪軟體的「例外處理設計與重構實作班 」12小時課程節錄而來，Teddy希望能夠傳達以下幾個觀念：
***
剛開始上課Teddy問了學生一些問題，台灣的學生都很客氣，可能是怕答錯或是太出風頭，不好意思回答問題。後來Teddy開玩笑說：「你們這樣我去寫部落格的時候只好寫某校的學生上課都沒反應」，經過刺激之後總算有幾個學生為了不被看扁勇敢發言。
下課休息時間有一位同學跑來問：「你剛剛講的local context與object context我還是不懂，能不能舉個例子？」因為例子已經從投影片中刪掉了，後來上課的時候Teddy把《笑談軟體工程：例外處理設計的逆襲》的電子檔打開，直接看書中的例子講解給學生聽。
這個問題，算是當天讓Teddy最開心的一件事。講到「例外處理的四個context」結束大概已經過了2小時，看大部分的學生都沒什麼反應原本Teddy想打混過去在這裡隨便交待一下就好，沒想到這一偷懶居然被人看出來有地方沒講清楚，這個問題讓Teddy有機會可以補充說明，也確定真的有人在聽。
***
這個故事提醒自己，〈就算只影響一個人〉還是要認真上課，不可以偷工減料啊XD。
***
友藏內心獨白：簽到是不是要送禮物？
August 04 11:30~12:28
▲蜜蜂算bug嗎？
前一陣子在Facebook看到朋友轉貼某人的文章，其中提到（為保護當事人，原文加以改寫）：
***
朋友轉貼文章，同時評論這個比喻真的是太好了。不過Teddy倒是覺得這個比喻很值得商榷。首先，語意不是很清楚，最有問題的就是第一句「隨機殺人嫌犯是社會的bug」，這句話是說：
如果真的要用bug打比方，Teddy覺得隨機殺人嫌犯並不是社會的bug，而是一隻有bug的程式或是process（行程）。社會就好比作業系統，每個人都是一隻程式，執行在作業系統上，與作業系統以及其他程式互動。
***
程式有bug怎麼辦？從錯誤處理的角度，如果是design fault（programming error），當然要修改程式，找到錯誤發生的根本原因。如果是component fault（環境或程式互動出了問題），要做好錯誤狀態回復然後可以嘗試retry。
Teddy認為隨機殺人行為應該屬於design fault，也就是程式本身有邏輯錯誤，所以解決方法要修改程式。但是並非所有的design fault都可以在短時間修復，如果修不好就重新執行，很可能對其他正常執行的程式（社會大眾）以及整個作業系統造成嚴重的傷害。那怎麼辦？沒關係，還有一招叫做隔離。至於要隔離多久請自行判斷。
此外，有bug的程式造成系統狀態不正確，修復錯誤狀態也是需要成本。狀態回復的成本，誰要負擔？ 從錯誤處理的角度來看，「終止有問題的程式執行」也是一種選項，為了不讓它造成更大傷害，有時候是不得不的選擇。
***
其實把人比喻成bug或是程式都不太合適，因為bug易修易測，人性難改且難測。Bug修不好還可以選擇整個程式砍掉重練，人可以嗎？！Teddy不是要討論贊成或反對廢死的議題，只是認為要打比喻的時候，應該要評估一下比喻的正確性會比較好一點。
***
友藏內心獨白：二十年後又是一條好漢
Oct. 20 22:20~22:51
上週六（10/18）Teddy在上「Design Patterns這樣學就會了：入門實作班」的時候，有一位學員跟Teddy說…
學員：我有買你的《笑談軟體工程：例外處理設計的逆襲》，我覺得裡面有一句話寫得很好。
Teddy內心獨白：什麼，只有一句話寫得很好？！
Teddy：那一句？
學員：不可以忽略例外。
Teddy：對啊，這是最基本的（就跟不可以亂丟垃圾、占用博愛座一樣
學員：我接手了一個案子，原本案子快要失敗被廢棄，因為產品非常不穩定，原來的開發人員也找不出問題。我接手之後，看了你的書就把所有被忽略的例外全部往外丟，至少讓程式達到強健度等級一。雖然這麼做一開始程式會一直當掉，但是反倒協助我很快找到問題出在哪裡，一個一個去解決。
Teddy：這樣很好啊。
學員：現在我已經把這個產品給救起來了，我覺得例外處理真的很有用，特別過來跟你說一聲。
Teddy：謝謝、謝謝，我還以為這種書都沒人要看啊，能幫上忙我也很高興。
***
友藏內心獨白：以上內容純屬事實。
June 09 10:02~10:26
Teddy的新書《笑談軟體工程：例外處理設計的逆襲》從5月20日出版至今約20天，已經有鄉民很仔細地把書讀完，並且找到兩個錯誤
俗話說：「知錯能改，善莫大焉」，趕快來更正一下目前找到的兩個錯誤。
***
錯誤一
第222頁，表27-1，行為回復的英文誤植為State-recovery，正確應該是Behavior-recovery。
錯誤二
第375頁，「視力測驗參考答案第6題」，正確答案是D。
***
錯誤三(2014/7/9新增)
第57頁，倒數第7行的「圖8-1」是錯的，正確為「圖8-2」。
***
感謝「CrazyStar」、「冷凍蝦米」、「陳傳興」回報這三個問題，請受Teddy一拜（鞠躬）。
***
友藏內心獨白：有問題歡迎隨時提出。
May 25 21:45~22:20
照片由張波妮提供。
上禮拜四Teddy終於拿到自己的新書《笑談軟體工程：例外處理設計的逆襲》。當初開始寫這本書的時候，Kay告訴Teddy：「不要對這本書的銷售量抱持太大期望，因為和敏捷開發相比，例外處理這個主題太冷門了。」書如果賣的好當然很開心，不過Teddy會花那麼多時間寫這本書主要是希望對「自己」有所交代，次要才是增加收入。當初念博士班的時候研究例外處理那麼多年，最後生出一本沒有人會去讀的博士論文
博士班畢業五年多，前三年在當上班族，要找出寫書的時間好難。加上每天處理一堆「人」的事情，也沒那個心思靜下心來寫書。後來陰錯陽差脫離上班族的身分，成立泰迪軟體，生活型態改變，有更多的時間可以寫作。即使如此，也是需要下定很大的決心，排除雜念與雜事，才有辦法寫好一本書。
***
有購買本書的鄉民，希望書中的內容對各位日後軟體開發能有所助益。歡迎大家有任何問題、心得、建議、感想，都可以留言或來信與Teddy分享。
書和馬克杯終於合體了XD。
***
友藏內心獨白：這樣算打書嗎？
May 14 21:12~21:41
Teddy的新書《笑談軟體工程：例外處理設計的逆襲》終於在今天（5月14日）送印，預計5月20日上市。別說鄉民等了很久，就連Teddy自己都等了好久啊
今天把書的目錄貼出來讓鄉民們瞭解本書的內容大概在講些什麼東東：
Part 1 例外處理的現況
01 你對例外處理的了解有多少？ 3
02 例外處理的重要性 5
03 種花電信，我真是猜不透你啊 13
04 HTC One X—發現一個Bug 21
05 HTC One X—我只是想打通電話呀 25
06 HTC One X—拍照的錯誤訊息描述 31
07 可靠性可以是一門生意 37
Column A. 帶賽的人很適合當神秘客 41
Part 2 例外處理基本觀念
08 強健性大戰首部曲—威脅潛伏 49
Column B. 找不到資料，要傳回Null還是丟出Exception？ 56
09 例外處理的四種脈絡 59
10 物件導向語言的例外處理機制 71
11 你的汽車有多耐撞？談談例外安全性 89
12 例外處理VS.容錯設計 93
Column C. 網路又斷了 98
Part 3 Java語言的例外處理機制
Java的Try、Catch、Finally 105
14 我的例外被Finally Block蓋台了 115
15 Suppressed Exception—搶救例外大作戰 121
16 表達清楚的Cleanup Failure語意 127
17 自己製作Suppressed Exception 137
18 Try、Catch、Finally的責任分擔 151
Column D. 這是你的問題，不是我的問題 160
19 例外處理失敗怎麼辦？ 165
20 Checked與Unchecked例外的語意與問題 169
21 介面演進 175
Part 4 為什麼例外處理那麼難？例外處理的4+1觀點
22 用途觀點 185
23 設計觀點 189
24 處理觀點 193
25 工具支援觀點 197
26 流程觀點 205
Column E. 你如何評價成功 213
Part 5 強健度等級與例外處理策略
例外處理設計的第一步—決定強健度等級 219
28 強健度等級１—錯誤回報的實作策略 229
29 強健度等級２—狀態回復的實作策略 235
30 強健度等級３—行為回復的實作策略 243
Column F. VMWare越獄之替代方案 251
31 例外類別設計與使用技巧 257
32 終止或繼續 269
33 自動化更新 273
Column G. 升級、降級，傻傻分不清楚 277
Part 6 例外處理壞味道與重構
34 例外處理壞味道 285
Column H. 仙人打鼓有時錯—談談Clean Code的例外處理 293
35 用例外代替錯誤碼 299
36 以非受檢例外取代忽略受檢例外 307
37 以非受檢例外取代虛設的例外處理程序 313
38 使用最外層Try敘述避免意外終止 319
39 以函數取代巢狀Try敘述 325
40 引入檢查點類別 333
41 引入多才多藝的Try區塊 341
Column I. 客戶滿意，老闆賺錢，你護肝 349
42 一個函數只能有一個Try敘述 359
Column J. 視力測驗 365
Appendix A 視力測驗參考答案 373
***
以上，敬請批評指教。讀本書若搭配Teddy特製的「例外處理馬克杯」一併服用，藥效更佳
ATM 轉帳
銀行代號 008 (華南銀行)
帳號：113100159221
匯 款
銀行名稱：華南銀行 新生分行
戶名：泰迪軟體科技有限公司 帳號：113100159221
***
友藏內心獨白：馬克杯正在加緊製作中。
May 5 17:38~18:04
Teddy的新書封面，預計五月中旬上市。
系統又當機了、程式執行地好好的，但狀態卻是錯的、找bug找了老半天也看不出個所以然來。以上症狀，原因很多，其中最常見的一項就是因為「不良的例外處理所導致的系統不穩定」。
身為專業軟體開發人員，從小到大你可能學過各式各樣的軟體設計技術與方法。從最基礎的程式語言、資料結構與演算法，到物件導向分析與設計、設計模式、軟體架構，以及各種敏捷開發實務做法，包含自動化測試、測試驅動開發、行為驅動開發、持續整合、敏捷設計原則等。以上，所有的大師費盡心力，都在告訴你一件事：「如何設計軟體的光明面，也就是「正常行為」（normal behavior）」。而Teddy要告訴鄉民們，如何對付軟體的黑暗面—也就是「異常行為」（abnormal behavior）。
***
第四梯次課程報名網址在此，本次課程學員可獲得好禮二選一：《笑談軟體工程：例外處理設計的逆襲》作者簽名書一本，或例外處理心法馬克杯一個。
印有例外處理心法的馬克杯
課程資訊如下。
日期：2014年06月14、15日，週六、日。
時間：09:30~16:30，共12小時。
地點：台北市 (上課前三天通知上課地點)
※ 課程內容與練習範例以Java語言為主，包含對C#語言的例外處理討論。
最後重複一次，報名網址在此。
***
友藏內心獨白：例外處理設計的書終於要上市了。
Feb. 25 21:20~21:50
今天在Facebook上看到一位朋友提到有人犯了「用例外處理取代控制流程（control flow）」的錯誤。有人把一個用來將性別由「男」或「女」轉成數字的函數checkSex()寫成下面這個樣子：
public void checkSex() throws Exception
if (sex == “男”) {
throw new MaleException();
} else if (sex == “女”) {
throw new FemaleException();
}
checkSex()沒有宣告傳回值，反倒是丟出了例外，用MaleException代表「男」，用FemaleException代表「女」。呼叫checkSex()的函數updateDatabase()大概長成下面這樣子：
public void updateDatabase(){
int sex;
try {
checkSex();
} catch(MaleException e){
sex = 0;
} catch(FemaleException e ) {
sex = 1;
}
…
}
***
以上程式可以通過測試案例，執行結果完全正確。但是，家裡面出了這種code，鄉民們您吞得下去嗎？Teddy真的是孤陋寡聞，可以把例外處理「玩」成這樣，而且還不是學生，而是「業界人士」所寫出的程式碼（疑，會不會是業界人士把案子外包給學生開發出來的程式？！），還真是第一次遇到。
checkSex()至少犯了兩個例外處理的基本錯誤：
這種錯誤是如此的顯而易見，以至於Teddy在寫《笑談軟體工程：例外處理設計的逆襲》這本書的時候根本就沒擺進去，沒想到還真的有人寫出這樣的程式。書還沒出版，難道要多寫一章…
***
友藏內心獨白：怎麼搞得好像只要不是文盲都可以來寫程式的說
Feb. 25 20:42~21:15
有一位上過Design Patterns與例外處理課程的「資深」學員，在上完例外處理課程的兩天後問了Teddy一個問題：
如果我今天使用Observer Pattern，是否儘量不要在Observer的update()上throw Exception？因為實作notify()的Subject並不知道如何處理各個Observer中發生的問題（沒有足夠context）？
***
回答這個問題之前先幫鄉民們複習一下Observer Pattern長成甚麼樣子：
Subject的notify()實作方式長成這樣：
for(Observer obj : _observers){
obj.update(this);
}
Teddy：如果Observer的update()丟出exception而 Subject 又沒有去 handle, 會把 Subject 搞掛掉。除非鄉民們在 Subject 的 notify()裡面去 catch(Throwable e) ，然後把丟出 exception 的 Observer 給 disable 或是針對他忽略這次的通知（但是要把例外 log 下來）。
學員：對啊因為我之前用Observer的時候就亂用，都在update上throws Exception，但完全沒想到處理它，可是真的有遇過就這樣把Subject搞掛的問題，昨天突然想到好像不該這麼搞。
Teddy：恭喜你已經把 exception handling 和 design pattern 結合在一起了
***
這位學員非常棒，能夠舉一反三。在上課的時候，Teddy讓學員們練習的例子是這個：
在Plug-in架構裡面，Plug-in和Host對於例外處理各應負擔什麼責任？轉換到Observer Pattern，Subject有點類似Host，而Observer就是Plug-in。所以在討論Plug-in架構的例外處理，自然可以套用在Observer Pattern上面。
***
Design pattern 是從設計「正常行為」角度出發，並沒有特別提到在實作design pattern時遇到「異常行為」要如何處理。例外處理是一種cross-cutting concern（橫切關注點），學會例外處理之後，不要說是實作每一個 pattern，在寫任何程式都可以派上用場。這位學員上完「例外處理設計與重構」之後可以有能力反思與應用在之前學過的design pattern上面，就算是有學通了。
來賓請掌聲鼓勵。
***
友藏內心獨白：要動腦筋。
Feb. 25 17:35~18:37
「例外處理設計與重構實作班」第三梯次，已經在2月22~23日順利結束。2013年上過兩梯次一日班，但因為課程內容「太豐富」，以至於壓縮到練習的時間。所以今年特別把課程調整成兩天，增加很多練習活動，還有把之前一日班無法排入的重要教材也一併加入。
以下是兩日班的課程大綱，除了練習活動以外，主要增加了「例外處理的4種Context」、「Checked和Unchecked Exception的優缺點比較」、「強健度等級1~3的實作方法」、以及「例外類別設計方法」。
***
這裡有之前「一日班課程實錄」，今天僅介紹2日班增加的內容。首先Fault分類除了原本的design fault與component fault，增加了以「發生時間長短」來分類的三種缺陷。這三種不同的缺陷也會影響例外處理策略的選擇。
例外處理機制由原本的6大因素增加為10大因素。
例外處理的四種context：exception、object、local、architecture，對於例外處理設計有非常重要的影響。
接著是checked exception與unchecked exception的介紹與比較。介紹完畢之後Teddy問了一個要花點腦筋思考的問題：
這次還有認真的練習一下try-catch-finally block的責任。
大家來動動腦，看看…要填些什麼內容。
接下來介紹達到強健度等級1、2、3的實作方法。
最後提到六個例外類別設計技巧，每一個都非常實用。
***
很多練習活動。
部分練習題，有業界實際案例分析。
***
兩天的課程時間安排了大量的練習，可以讓學員們當場印證Teddy課堂上所講的內容，效果更佳。
***
友藏內心獨白：例外處理是一條鞭。
![image[3] (11)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRqWseZ5NP-EGiOcKtC4kI-5nSTCJlZGEYkalaVjqKl6x3dPaqvo0Nc6WwGCvHs-_wzlmNnUxwfzFvklTm-taNp0KBMi3L0dM_I5w7SDHz1SW5ROIUGgrf4qvqoQMQ5tg3TqzdBwLB5imG/s1600-h/image%25255B3%25255D%252520%25252811%252529%25255B4%25255D.png "image[3] (11)")
