go入门教程- 16.10 糟糕的错误处理

  1. 16.10 糟糕的错误处理
    1. 16.10.1 不要使用布尔值:
    2. 16.10.2 避免错误检测使代码变得混乱:
    3. 链接

16.10 糟糕的错误处理

译者注:该小结关于错误处理的观点,译者并不完全赞同,关于本小结的部分想法请参考关于16.10.2小节错误处理的一些见解

依附于第13章模式的描述和第17.1小节第17.2.4小节的总结。

16.10.1 不要使用布尔值:

像下面代码一样,创建一个布尔型变量用于测试错误条件是多余的:

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

立即检测一个错误:

1
2
... err1 := api.Func1()
if err1 != nil { … }

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

避免写出这样的代码:

1
2
3
4
5
6
7
8
9
10
... err1 := api.Func1()
if err1 != nil {
fmt.Println("err: " + err.Error())
return
}
err2 := api.Func2()
if err2 != nil {
...
return
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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模式的情况。

链接


免责声明:本页面内容均来源于站内编辑发布,部分信息来源互联网,并不意味着本站赞同其观点或者证实其内容的真实性,如涉及版权等问题,请立即联系客服进行更改或删除,保证您的合法权益。转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com

推荐阅读:

文章标题:go入门教程- 16.10 糟糕的错误处理

本文作者:知识铺

发布时间:2019-10-15, 22:30:20

最后更新:2019-10-16, 21:00:38

原始链接:https://blog.zshipu.com/2019/10/15/golang/20191015/16.10/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

目录
×

喜欢就点赞,疼爱就打赏