16.10 糟糕的错误处理
译者注：该小结关于错误处理的观点，译者并不完全赞同，关于本小结的部分想法请参考关于16.10.2小节错误处理的一些见解
依附于第13章模式的描述和第17.1小节与第17.2.4小节的总结。
16.10.1 不要使用布尔值：
像下面代码一样，创建一个布尔型变量用于测试错误条件是多余的：
var good bool
// 测试一个错误，`good`被赋为`true`或者`false`
if !good {
return errors.New("things aren’t good")
}
立即检测一个错误：
... err1 := api.Func1()
if err1 != nil { … }
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() ...
聚合一些更有价值的编程书籍/教程/文档 2020回归技术纯粹，相信时间的力量，做时间的朋友 -- 前端进阶资源教程@Js中文网
这种方法可以很容易分辨出错误检测、错误通知和正常的程序逻辑（更详细的方式参考第13.5小节）。
在开始阅读第17章前，先回答下列2个问题：
问题 16.1：总结你能记住的所有关于
,ok模式的情况。问题 16.2：总结你能记住的所有关于
defer模式的情况。
链接
看完两件小事
如果你觉得这篇文章对你挺有启发，我想请你帮我两个小忙：
- 把这篇文章分享给你的朋友 / 交流群，让更多的人看到，一起进步，一起成长！
- 关注公众号 「IT平头哥联盟」，公众号后台回复「资源」 免费领取我精心整理的前端进阶资源教程
