gopl-zh.github.com/ch5/ch5-10.md
2020-02-02 17:45:17 +08:00

5.3 KiB
Raw Blame History

5.10. Recover捕获异常

通常来说不应该对panic异常做任何处理但有时也许我们可以从异常中恢复至少我们可以在程序崩溃前做一些操作。举个例子当web服务器遇到不可预料的严重问题时在崩溃前应该将所有的连接关闭如果不做任何处理会使得客户端一直处于等待状态。如果web服务器还在开发阶段服务器甚至可以将异常信息反馈到客户端帮助调试。

如果在deferred函数中调用了内置函数recover并且定义该defer语句的函数发生了panic异常recover会使程序从panic中恢复并返回panic value。导致panic异常的函数不会继续运行但能正常返回。在未发生panic时调用recoverrecover会返回nil。

让我们以语言解析器为例说明recover的使用场景。考虑到语言解析器的复杂性即使某个语言解析器目前工作正常也无法肯定它没有漏洞。因此当某个异常出现时我们不会选择让解析器崩溃而是会将panic异常当作普通的解析错误并附加额外信息提醒用户报告此错误。

func Parse(input string) (s *Syntax, err error) {
	defer func() {
		if p := recover(); p != nil {
			err = fmt.Errorf("internal error: %v", p)
		}
	}()
	// ...parser...
}

deferred函数帮助Parse从panic中恢复。在deferred函数内部panic value被附加到错误信息中并用err变量接收错误信息返回给调用者。我们也可以通过调用runtime.Stack往错误信息中添加完整的堆栈调用信息。

不加区分的恢复所有的panic异常不是可取的做法因为在panic之后无法保证包级变量的状态仍然和我们预期一致。比如对数据结构的一次重要更新没有被完整完成、文件或者网络连接没有被关闭、获得的锁没有被释放。此外如果写日志时产生的panic被不加区分的恢复可能会导致漏洞被忽略。

虽然把对panic的处理都集中在一个包下有助于简化对复杂和不可以预料问题的处理但作为被广泛遵守的规范你不应该试图去恢复其他包引起的panic。公有的API应该将函数的运行失败作为error返回而不是panic。同样的你也不应该恢复一个由他人开发的函数引起的panic比如说调用者传入的回调函数因为你无法确保这样做是安全的。

有时我们很难完全遵循规范举个例子net/http包中提供了一个web服务器将收到的请求分发给用户提供的处理函数。很显然我们不能因为某个处理函数引发的panic异常杀掉整个进程web服务器遇到处理函数导致的panic时会调用recover输出堆栈信息继续运行。这样的做法在实践中很便捷但也会引起资源泄漏或是因为recover操作导致其他问题。

基于以上原因安全的做法是有选择性的recover。换句话说只恢复应该被恢复的panic异常此外这些异常所占的比例应该尽可能的低。为了标识某个panic是否应该被恢复我们可以将panic value设置成特殊类型。在recover时对panic value进行检查如果发现panic value是特殊类型就将这个panic作为error处理如果不是则按照正常的panic进行处理在下面的例子中我们会看到这种方式

下面的例子是title函数的变形如果HTML页面包含多个<title>该函数会给调用者返回一个错误error。在soleTitle内部处理时如果检测到有多个<title>会调用panic阻止函数继续递归并将特殊类型bailout作为panic的参数。

// soleTitle returns the text of the first non-empty title element
// in doc, and an error if there was not exactly one.
func soleTitle(doc *html.Node) (title string, err error) {
	type bailout struct{}
	defer func() {
		switch p := recover(); p {
		case nil:       // no panic
		case bailout{}: // "expected" panic
			err = fmt.Errorf("multiple title elements")
		default:
			panic(p) // unexpected panic; carry on panicking
		}
	}()
	// Bail out of recursion if we find more than one nonempty title.
	forEachNode(doc, func(n *html.Node) {
		if n.Type == html.ElementNode && n.Data == "title" &&
			n.FirstChild != nil {
			if title != "" {
				panic(bailout{}) // multiple titleelements
			}
			title = n.FirstChild.Data
		}
	}, nil)
	if title == "" {
		return "", fmt.Errorf("no title element")
	}
	return title, nil
}

在上例中deferred函数调用recover并检查panic value。当panic value是bailout{}类型时deferred函数生成一个error返回给调用者。当panic value是其他non-nil值时表示发生了未知的panic异常deferred函数将调用panic函数并将当前的panic value作为参数传入此时等同于recover没有做任何操作。请注意在例子中对可预期的错误采用了panic这违反了之前的建议我们在此只是想向读者演示这种机制。

有些情况下我们无法恢复。某些致命错误会导致Go在运行时终止程序如内存不足。

练习5.19 使用panic和recover编写一个不包含return语句但能返回一个非零值的函数。