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