? ? ? ?第七章作者介紹錯(cuò)誤處理的技巧和要考慮的地方，Try-Catch-Finally必定都會(huì)用到。錯(cuò)誤處理程式不可以干擾主體程式。

使用例外事件而非回傳錯(cuò)誤碼

古早時(shí)代程式發(fā)生錯(cuò)誤會(huì)回傳錯(cuò)誤狀態(tài)或是設(shè)定錯(cuò)誤旗標(biāo)，如7-1。

古早方法會(huì)讓程式變得雜亂，影響原本的程式。遇到錯(cuò)誤的時(shí)候，拋出一個(gè)例外，會(huì)讓程式碼乾淨(jìng)許多。7-2 是使用例外的方法。

在開頭寫下你的Try-Catch-Finally 敘述

try{

正常程式

}catch(e){

例外處理程式

}

Try區(qū)塊放正常程式

Catch區(qū)塊放例外處理程式

使用不檢查型例外(Use Unchecked Exceptions)

Java支援檢查型例外(Checked Exceptions)

C#,C++,Python與Ruby都不支援檢查型例外。

檢查型例(Checked Exceptions)外違反開放閉合準(zhǔn)則（OCP），對軟體底層的修改，也會(huì)影響軟體高層的部分。

提供發(fā)生例外的相關(guān)資訊

例外發(fā)生的時(shí)候要提供足夠的資訊

哪個(gè)操作發(fā)生錯(cuò)誤

錯(cuò)誤的型態(tài)

發(fā)生例外的時(shí)間

跳出例外的地點(diǎn)

通常也會(huì)寫log檔案記錄例外訊息

從呼叫者的角度定義例外類別

看範(fàn)例可知作者的意思，作者提到一個(gè)非常重要的程式技巧包裹（wrap），可以大幅化簡程式。

包裹（wrap）第三方API的好處

減少對第三方API的依賴，可快速更換第三方API

可模擬第三方API的呼叫，協(xié)助測試

化繁為簡變得只定義單一型態(tài)的例外

定義正常的程式流程

看範(fàn)例可知Catch區(qū)塊不應(yīng)該放商業(yè)法則程式。

SPECIAL CASE PATTERN（特殊情況模式）建立一個(gè)類別處理特殊情況，總是回傳物件，客戶端就不必處理例外行為。

不要回傳null (空值)

作者批評(píng)有的程式太多檢查物件是否為null，回傳例外事件或是回傳物件，不要回傳null。

若有第三方API會(huì)回傳null，可用包裹（wrap）的方法改成拋出例外或是回傳特殊情況物件。

不要傳遞null

不要將null當(dāng)參數(shù)傳遞到函數(shù)，範(fàn)例可看出函數(shù)為了要檢查null，又增加許多程式碼。

總結(jié)

Clean Code 必須易讀且耐用，錯(cuò)誤處理程式與主要邏輯程式要分開，程式才容易維護(hù)。