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() ...

这种方法可以很容易分辨出错误检测、错误通知和正常的程序逻辑（更详细的方式参考第 13.5 小节）。

在开始阅读第 17 章前，先回答下列 2 个问题：

问题 16.1：总结你能记住的所有关于 , ok 模式的情况。
问题 16.2：总结你能记住的所有关于 defer 模式的情况。

masx200 / the-way-to-go_ZH_CN

16.10 糟糕的错误处理

16.10.1 不要使用布尔值：

16.10.2 避免错误检测使代码变得混乱：

链接

简介

发行版

贡献者

近期动态

masx200 / the-way-to-go_ZH_CN .gitee-modal { width: 500px !important; }

16.10 糟糕的错误处理

16.10.1 不要使用布尔值：

16.10.2 避免错误检测使代码变得混乱：

链接

简介

发行版

开源评估指数源自 OSS-Compass 评估体系，评估体系围绕以下三个维度对项目展开评估：

贡献者

近期动态

搜索帮助

masx200 / the-way-to-go_ZH_CN