依附于[第13章](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/13.0.md)模式的描述和[第17.1小節](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/17.1.md)與[第17.2.4小節](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/17.2.md)的總結。 ## [](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/16.10.md#16101-不要使用布爾值)16.10.1 不要使用布爾值： 像下面代碼一樣，創建一個布爾型變量用于測試錯誤條件是多余的： ~~~ var good bool // 測試一個錯誤，`good`被賦為`true`或者`false` if !good { return errors.New("things aren’t good") } ~~~ 立即檢測一個錯誤： ~~~ ... err1 := api.Func1() if err1 != nil { … } ~~~ ## [](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/16.10.md#16102-避免錯誤檢測使代碼變得混亂)16.10.2 避免錯誤檢測使代碼變得混亂： 避免寫出這樣的代碼： ~~~ ... err1 := api.Func1() if err1 != nil { fmt.Println("err: " + err.Error()) return } err2 := api.Func2() if err2 != nil { ... return } ~~~ 首先，包括在一個初始化的`if`語句中對函數的調用。但即使代碼中到處都是以`if`語句的形式通知錯誤（通過打印錯誤信息）。通過這種方式，很難分辨什么是正常的程序邏輯，什么是錯誤檢測或錯誤通知。還需注意的是，大部分代碼都是致力于錯誤的檢測。通常解決此問題的好辦法是盡可能以閉包的形式封裝你的錯誤檢測，例如下面的代碼： ~~~ func httpRequestHandler(w http.ResponseWriter, req *http.Request) { err := func () error { if req.Method != "GET" { return errors.New("expected GET") } if input := parseInput(req); input != "command" { return errors.New("malformed command") } // 可以在此進行其他的錯誤檢測 } () if err != nil { w.WriteHeader(400) io.WriteString(w, err) return } doSomething() ... ~~~ 這種方法可以很容易分辨出錯誤檢測、錯誤通知和正常的程序邏輯（更詳細的方式參考[第13.5小節](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/13.5.md)）。 在開始閱讀[第17章](https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/17.0.md)前，先回答下列2個問題： * 問題 16.1：總結你能記住的所有關于`,ok`模式的情況。 * 問題 16.2：總結你能記住的所有關于`defer`模式的情況。