gopl-zh.github.com/ch5/ch5-04.md

191 lines
12 KiB
Markdown
Raw Normal View History

2016-02-15 03:06:34 +00:00
## 5.4. 错误
2015-12-09 07:45:11 +00:00
2016-02-15 03:06:34 +00:00
在Go中有一部分函数总是能成功的运行。比如strings.Contains和strconv.FormatBool函数对各种可能的输入都做了良好的处理使得运行时几乎不会失败除非遇到灾难性的、不可预料的情况比如运行时的内存溢出。导致这种错误的原因很复杂难以处理从错误中恢复的可能性也很低。
2016-01-05 15:46:55 +00:00
2017-08-24 14:27:42 +00:00
还有一部分函数只要输入的参数满足一定条件也能保证运行成功。比如time.Date函数该函数将年月日等参数构造成time.Time对象除非最后一个参数时区是nil。这种情况下会引发panic异常。panic是来自被调用函数的信号表示发生了某个已知的bug。一个良好的程序永远不应该发生panic异常。
2016-01-05 15:46:55 +00:00
2017-07-11 14:06:42 +00:00
对于大部分函数而言永远无法确保能否成功运行。这是因为错误的原因超出了程序员的控制。举个例子任何进行I/O操作的函数都会面临出现错误的可能只有没有经验的程序员才会相信读写操作不会失败即使是简单的读写。因此当本该可信的操作出乎意料的失败后我们必须弄清楚导致失败的原因。
2016-01-05 15:46:55 +00:00
2016-02-15 03:06:34 +00:00
在Go的错误处理中错误是软件包API和应用程序用户界面的一个重要组成部分程序运行失败仅被认为是几个预期的结果之一。
2016-01-05 15:46:55 +00:00
2016-02-15 03:06:34 +00:00
对于那些将运行失败看作是预期结果的函数它们会返回一个额外的返回值通常是最后一个来传递错误信息。如果导致失败的原因只有一个额外的返回值可以是一个布尔值通常被命名为ok。比如cache.Lookup失败的唯一原因是key不存在那么代码可以按照下面的方式组织
2016-01-06 01:39:11 +00:00
```Go
2016-01-05 15:46:55 +00:00
value, ok := cache.Lookup(key)
if !ok {
2016-01-06 01:39:11 +00:00
// ...cache[key] does not exist…
2016-01-05 15:46:55 +00:00
}
```
2016-01-06 01:39:11 +00:00
2016-02-15 03:06:34 +00:00
通常导致失败的原因不止一种尤其是对I/O操作而言用户需要了解更多的错误信息。因此额外的返回值不再是简单的布尔类型而是error类型。
2016-01-05 15:46:55 +00:00
2018-05-27 20:51:15 +00:00
内置的error是接口类型。我们将在第七章了解接口类型的含义以及它对错误处理的影响。现在我们只需要明白error类型可能是nil或者non-nil。nil意味着函数运行成功non-nil表示失败。对于non-nil的error类型我们可以通过调用error的Error函数或者输出函数获得字符串类型的错误信息。
2016-01-06 01:39:11 +00:00
```Go
2016-01-05 15:46:55 +00:00
fmt.Println(err)
fmt.Printf("%v", err)
```
2016-01-06 01:39:11 +00:00
2018-06-09 16:27:25 +00:00
通常当函数返回non-nil的error时其他的返回值是未定义的undefined这些未定义的返回值应该被忽略。然而有少部分函数在发生错误时仍然会返回一些有用的返回值。比如当读取文件发生错误时Read函数会返回可以读取的字节数以及错误信息。对于这种情况正确的处理方式应该是先处理这些不完整的数据再处理错误。因此对函数的返回值要有清晰的说明以便于其他人使用。
2016-01-05 15:46:55 +00:00
2016-02-15 03:06:34 +00:00
在Go中函数运行失败时会返回错误信息这些错误信息被认为是一种预期的值而非异常exception这使得Go有别于那些将函数运行失败看作是异常的语言。虽然Go有各种异常机制但这些机制仅被使用在处理那些未被预料到的错误即bug而不是那些在健壮程序中应该被避免的程序错误。对于Go的异常机制我们将在5.9介绍。
2016-01-05 15:46:55 +00:00
2017-08-24 14:27:42 +00:00
Go这样设计的原因是由于对于某个应该在控制流程中处理的错误而言将这个错误以异常的形式抛出会混乱对错误的描述这通常会导致一些糟糕的后果。当某个程序错误被当作异常处理后这个错误会将堆栈跟踪信息返回给终端用户这些信息复杂且无用无法帮助定位错误。
2016-01-05 15:46:55 +00:00
2017-08-24 14:27:42 +00:00
正因此Go使用控制流机制如if和return处理错误这使得编码人员能更多的关注错误处理。
2016-01-02 14:12:38 +00:00
2022-08-04 06:58:52 +00:00
### 5.4.1. 错误处理策略
2016-01-02 14:12:38 +00:00
2022-08-04 06:58:52 +00:00
当一次函数调用返回错误时,调用者应该选择合适的方式处理错误。根据情况的不同,有很多处理方式,让我们来看看常用的五种方式。
首先也是最常用的方式是传播错误。这意味着函数中某个子程序的失败会变成该函数的失败。下面我们以5.3节的findLinks函数作为例子。如果findLinks对http.Get的调用失败findLinks会直接将这个HTTP错误返回给调用者
```Go
resp, err := http.Get(url)
if err != nil{
return nil, err
}
```
当对html.Parse的调用失败时findLinks不会直接返回html.Parse的错误因为缺少两条重要信息1、发生错误时的解析器html parser2、发生错误的url。因此findLinks构造了一个新的错误信息既包含了这两项也包括了底层的解析出错的信息。
```Go
doc, err := html.Parse(resp.Body)
resp.Body.Close()
if err != nil {
return nil, fmt.Errorf("parsing %s as HTML: %v", url,err)
}
```
fmt.Errorf函数使用fmt.Sprintf格式化错误信息并返回。我们使用该函数添加额外的前缀上下文信息到原始错误信息。当错误最终由main函数处理时错误信息应提供清晰的从原因到后果的因果链就像美国宇航局事故调查时做的那样
```
genesis: crashed: no parachute: G-switch failed: bad relay orientation
```
由于错误信息经常是以链式组合在一起的所以错误信息中应避免大写和换行符。最终的错误信息可能很长我们可以通过类似grep的工具处理错误信息译者注grep是一种文本搜索工具
编写错误信息时,我们要确保错误信息对问题细节的描述是详尽的。尤其是要注意错误信息表达的一致性,即相同的函数或同包内的同一组函数返回的错误在构成和处理方式上是相似的。
以os包为例os包确保文件操作如os.Open、Read、Write、Close返回的每个错误的描述不仅仅包含错误的原因如无权限文件目录不存在也包含文件名这样调用者在构造新的错误信息时无需再添加这些信息。
一般而言被调用函数f(x)会将调用信息和参数信息作为发生错误时的上下文放在错误信息中并返回给调用者调用者需要添加一些错误信息中不包含的信息比如添加url到html.Parse返回的错误中。
让我们来看看处理错误的第二种策略。如果错误的发生是偶然性的,或由不可预知的问题导致的。一个明智的选择是重新尝试失败的操作。在重试时,我们需要限制重试的时间间隔或重试的次数,防止无限制的重试。
<u><i>gopl.io/ch5/wait</i></u>
```Go
// WaitForServer attempts to contact the server of a URL.
// It tries for one minute using exponential back-off.
// It reports an error if all attempts fail.
func WaitForServer(url string) error {
const timeout = 1 * time.Minute
deadline := time.Now().Add(timeout)
for tries := 0; time.Now().Before(deadline); tries++ {
_, err := http.Head(url)
if err == nil {
return nil // success
}
log.Printf("server not responding (%s);retrying…", err)
time.Sleep(time.Second << uint(tries)) // exponential back-off
}
return fmt.Errorf("server %s failed to respond after %s", url, timeout)
}
```
如果错误发生后程序无法继续运行我们就可以采用第三种策略输出错误信息并结束程序。需要注意的是这种策略只应在main中执行。对库函数而言应仅向上传播错误除非该错误意味着程序内部包含不一致性即遇到了bug才能在库函数中结束程序。
```Go
// (In function main.)
if err := WaitForServer(url); err != nil {
fmt.Fprintf(os.Stderr, "Site is down: %v\n", err)
os.Exit(1)
}
```
调用log.Fatalf可以更简洁的代码达到与上文相同的效果。log中的所有函数都默认会在错误信息之前输出时间信息。
```Go
if err := WaitForServer(url); err != nil {
log.Fatalf("Site is down: %v\n", err)
}
```
长时间运行的服务器常采用默认的时间格式,而交互式工具很少采用包含如此多信息的格式。
```
2006/01/02 15:04:05 Site is down: no such domain:
bad.gopl.io
```
我们可以设置log的前缀信息屏蔽时间信息一般而言前缀信息会被设置成命令名。
```Go
log.SetPrefix("wait: ")
log.SetFlags(0)
```
第四种策略有时我们只需要输出错误信息就足够了不需要中断程序的运行。我们可以通过log包提供函数
```Go
if err := Ping(); err != nil {
log.Printf("ping failed: %v; networking disabled",err)
}
```
或者标准错误流输出错误信息。
```Go
if err := Ping(); err != nil {
fmt.Fprintf(os.Stderr, "ping failed: %v; networking disabled\n", err)
}
```
log包中的所有函数会为没有换行符的字符串增加换行符。
第五种,也是最后一种策略:我们可以直接忽略掉错误。
```Go
dir, err := ioutil.TempDir("", "scratch")
if err != nil {
return fmt.Errorf("failed to create temp dir: %v",err)
}
// ...use temp dir…
os.RemoveAll(dir) // ignore errors; $TMPDIR is cleaned periodically
```
尽管os.RemoveAll会失败但上面的例子并没有做错误处理。这是因为操作系统会定期的清理临时目录。正因如此虽然程序没有处理错误但程序的逻辑不会因此受到影响。我们应该在每次函数调用后都养成考虑错误处理的习惯当你决定忽略某个错误时你应该清晰地写下你的意图。
在Go中错误处理有一套独特的编码风格。检查某个子函数是否失败后我们通常将处理失败的逻辑代码放在处理成功的代码之前。如果某个错误会导致函数返回那么成功时的逻辑代码不应放在else语句块中而应直接放在函数体中。Go中大部分函数的代码结构几乎相同首先是一系列的初始检查防止错误发生之后是函数的实际逻辑。
### 5.4.2. 文件结尾错误EOF
函数经常会返回多种错误这对终端用户来说可能会很有趣但对程序而言这使得情况变得复杂。很多时候程序必须根据错误类型作出不同的响应。让我们考虑这样一个例子从文件中读取n个字节。如果n等于文件的长度读取过程的任何错误都表示失败。如果n小于文件的长度调用者会重复的读取固定大小的数据直到文件结束。这会导致调用者必须分别处理由文件结束引起的各种错误。基于这样的原因io包保证任何由文件结束引起的读取失败都返回同一个错误——io.EOF该错误在io包中定义
```Go
package io
import "errors"
// EOF is the error returned by Read when no more input is available.
var EOF = errors.New("EOF")
```
调用者只需通过简单的比较就可以检测出这个错误。下面的例子展示了如何从标准输入中读取字符以及判断文件结束。4.3的chartcount程序展示了更加复杂的代码
```Go
in := bufio.NewReader(os.Stdin)
for {
r, _, err := in.ReadRune()
if err == io.EOF {
break // finished reading
}
if err != nil {
return fmt.Errorf("read failed:%v", err)
}
// ...use r…
}
```
因为文件结束这种错误不需要更多的描述所以io.EOF有固定的错误信息——“EOF”。对于其他错误我们可能需要在错误信息中描述错误的类型和数量这使得我们不能像io.EOF一样采用固定的错误信息。在7.11节中,我们会提出更系统的方法区分某些固定的错误值。