前幾章提到的大多是局部性的程式撰寫建議，
我也把這本書放在工作桌旁，隨時修正現在的撰寫習慣，
前幾章的例子很快地就能說服我這樣的作法是較好的，
其實在這本書剛出版時就已經購入了，
但當時還是學生，沒寫過較具規模的程式，
因此看這本書時一點體會都沒有，很快地就看不下去。
去年寫了一個較完整自動化機台的其中一部分，
但錯誤處理的部分一直不知道該如何配置與規劃，
也就學著前輩的程式碼，以回傳錯誤碼的方式進行錯誤處理，
絲毫沒有考慮過以例外進行處理或回報，
但看到Clean Code不斷地提到錯誤應以例外進行處理，
不但可以保持程式碼整潔，也更能符合開放閉合原則，
即是宣告新的Exception Class取代不斷增加錯誤碼，
看了書中幾個例子後，也就先暫停Clean Code第七章錯誤處理的部分，
先好好了解一下C++與C#中例外該注意哪些重點。
我手上有兩本工具書，個別先把例外部份先完整看過一次：
Essential C# 7.0 : 第五章與第十一章
C++ Primer : 第六章與第十七章
兩者都提到且較基本的我就不紀錄了，提到的觀念其實差不多
仔細看收穫不少，尤其是C++ Primer接著在例外章節後對於debug部分提供很多幫助，
這邊想筆記一些書中的重點與思考比較久的部分，
例如C++中的例外以non-reference、reference、pointer三種形式的差異，一些語法規範。
[以下內容都是擷取自書中或其他部落格，並加上自己的理解，如有錯誤，還請指正。]
- Clean Code
- 使用例外事件取代回傳錯誤碼
- 能夠建立相對應的處理類別，我想這樣管理錯誤處理應該會更有系統，什麼例外就對應至相對應的處理類別。
- 例外的設計原意是允許你在較遠處才處理錯誤
- 我另外想到的是，假設以回傳錯誤碼的方式，那處理該錯誤碼的位置又很上層的話，如果沒有在第一時間處理錯誤碼，這樣回傳路徑上的每一層就都要寫出錯誤碼的回傳，但如果例外Exception，就不用寫return去回傳結果，也不會佔用return回備資訊這個管道，並可以統一在邏輯控制層處理這些傳出來的Exception，讓Exception的管理位置可以更統一與明瞭。
- 使用不檢查型例外(不使用明確型別的例外的意思)
- Clean Code是以Java作為範例，簡單來說就是宣告Function當下也必須宣告會丟出的Exception型別，這麼做的好處是編譯器會檢查function中可能會丟出的例外和你宣告的是否相同，但這麼做的代價是違反開放閉合原則，書中舉例，假設Try-Catch寫在三層之外的地方，那麼你就必須替拋出例外與catch之間的所有方法，在方法宣告處都加上該例外的宣告，一但較底層的例外修改了，那麼這一大串也將必須修改。
- 要注意，C++也可以在函式宣告中宣告出會丟出的例外，但編譯器是不會檢查的！主要是讓人了解這內部會丟出什麼例外，或完全不會丟出例外等等情形。
- 如果多個例外被catch後的處理方式都差不多的話，其實可以重新包裝成一個例外類別，讓code更加簡潔。
- 包裝成新的類別可以減少對原類別的依賴，日後要替換不同的類別或進行測試都相當有幫助。
- 我們常常對程式中的變數進行null的檢查，不如改為throw exception或是Special Case物件(對於什麼是special case我還沒有很深的體會)
- 看到一個段落，我有個小結論，return只負責正常程式邏輯的回傳結果，不負責錯誤訊息的傳遞，錯誤訊息一率透過throw exception，且附帶資訊。
例外處理其實應該可以有更多內容來說明，
但市面上好像只有一本已經絕版的書籍專門討論例外處理的技巧(例外處理設計的逆襲)，
重點是想買二手也買不到了(看到有人開價1500...)，
好加在公司圖書館有存書，是可以借來研究一下了。
今天找了前輩簡單談一下，
為什麼目前公司內部主要還是透過回傳error code的方式進行錯誤回報?
而不考慮使用throw的方式回報錯誤，
前輩說，因為這樣要花太多時間另外寫exception了...
看來有機會的話我再自己增加這部分到我自己的專案吧，
如果成效不錯，我想其他同仁也會願意嘗試的。
應該沒有人會完整看完這一篇筆記吧，篇幅的確有點長，
但我認為很多內容是一般入門程式書籍(大學買的第一本C++、C#等)不會提到的，
不妨將這篇文章作為參考資訊，
交叉檢視自己是否漏了什麼資訊是沒有從手邊的書中得到的，
再進一步深入了解。
由於篇幅實在太長，
由於篇幅實在太長，
所以將另外兩本書的內容分開放，才不會有看不完的感覺，應該也更好閱讀。
沒有留言:
張貼留言