golang 糟糕的错误处理

关于golang���糟糕错误处理，我持反对意见，因此写个博客记录一下

（）

golang的书中说：像下面代码一样，创建一个布尔型变量用于测试错误条件是多余的：

然而在个人看来，代码非常完美，言简意赅，一个bool就控制了if条件，多么清晰，golang设计者一点也没考虑实际业务场景

（）

var good bool    // 测试一个错误，`good` 被赋为 `true` 或者 `false`    if !good {        return errors.New("things aren’t good")    }

书中还说了：避免错误检测使代码变得混乱：避免写出这样的代码：

个人看法：golang的语言设计者，完全没考虑实际业务场景和开发人员会遇到什么样的开发场景，遇到什么样的产品，遇到什么样的开发周期，当需求来了要你今天开发，明天就上线，就只能这样写代码，语言的设计者就设定了代码中不得不出现很多的err的判断，又说这个很混乱，简直是自取其辱！~

... err1 := api.Func1()if err1 != nil {    fmt.Println("err: " + err.Error())    return}err2 := api.Func2()if err2 != nil {...    return}    

书里面又说了：首先，包括在一个初始化的 if 语句中对函数的调用。但即使代码中到处都是以 if 语句的形式通知错误（通过打印错误信息）。通过这种方式，很难分辨什么是正常的程序逻辑，什么是错误检测或错误通知。还需注意的是，大部分代码都是致力于错误的检测。通常解决此问题的好办法是尽可能以闭包的形式封装你的错误检测，例如下面的代码：

个人看法：首先，下面的代码确实要优雅一些，但是，实际场景，不可能这么完美，出入参，方法A是结构体，方法B是数组，方法C是字符串，根本不能写一个handler来全部处理，设计的人既然想到了使用handler来举例统一处理请求的检查，为什么就非要设定err呢？

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