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