4.1 问题的演化

错误 error 在 Go 中表现为一个内建的接口类型，任何实现了 Error() string 方法的类型都能作为 error 类型进行传递，成为错误值：

1
2
3
type error interface {
	Error() string
}

作为内建接口类型，编译器负责在参数传递检查时，对值类型所实现的方法进行检查。当类型实现了 Error() string 方法后，才允许其作为 error 进行传递：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
// go/src/cmd/compile/internal/gc/universe.go
func makeErrorInterface() *types.Type {
	field := types.NewField()
	field.Type = types.Types[TSTRING]
	f := functypefield(fakeRecvField(), nil, []*types.Field{field})

	// 查找是否实现了 Error
	field = types.NewField()
	field.Sym = lookup("Error")
	field.Type = f

	t := types.New(TINTER)
	t.SetInterface([]*types.Field{field})
	return t
}

4.1.1 错误的历史形态

早期的 Go 甚至没有错误处理 [Gerrand, 2010] [Cox, 2019b]，当时的 os.Read 函数进行系统调用可能产生错误，而该接口是通过 int64 类型进行错误返回的：

1
2
3
4
export func Read(fd int64, b *[]byte) (ret int64, errno int64) {
	r, e := syscall.read(fd, &b[0], int64(len(b)));
	return r, e
}

随后，Go 团队将这一 errno 转换抽象成了一个类型：

1
2
3
4
5
6
7
8
9
export type Error struct { s string }

func (e *Error) Print() { ... }
func (e *Error) String() string { ... }

export func Read(fd int64, b *[]byte) (ret int64, err *Error) {
	r, e := syscall.read(fd, &b[0], int64(len(b)));
	return r, ErrnoToError(e)
}

之后才演变为了 Go 1 中被人们熟知的 error 接口类型。

可见之所以从理解上我们可以将 error 认为是一个接口，是因为在编译器实现中，是通过查询某个类型是否实现了 Error 方法来创建 Error 类型的。

4.1.2 处理错误的基本策略

由于 Go 中的错误处理设计得非常简洁，在其他现代编程语言里都几乎找不见此类做法。 Go 团队也曾多次撰写文章来教导 Go 语言的用户 [Gerrand, 2011] [Pike, 2015]。无论怎样，非常常见的策略包含哨兵错误、自定义错误以及隐式错误三种。

哨兵错误

哨兵错误的处理方式通过特定值表示成功和不同错误，依靠调用方对错误进行检查：

1
if err === ErrSomething { ... }

例如，比较著名的 io.EOF = errors.New("EOF")。

这种错误处理的方式引入了上下层代码的依赖，如果被调用方的错误类型发生了变化，则调用方也需要对代码进行修改：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
func readf(path string) error {
	err := file.Open(path)
	if err != nil {
		return fmt.Errorf("cannot open file: %v", err)
	}
}

func main() {
	err := readf("~/.ssh/id_rsa.pub")
	if strings.Contains(err.Error(), "not found") {
		...
	}
}

这类错误处理的方式是非常危险的，因为它在调用方和被调用方之间建立了牢不可破的依赖关系。除此之外，哨兵错误还有一个相当致命的危险，那就是这种方式所定义的错误并非常量，例如：

1
2
package io
var EOF = errors.New("EOF")

而当我们将此错误类型公开给其他包使用后，我们非常难以避免这种事情发生：

1
2
3
4
5
package main
import "io"
func init() {
	io.EOF = nil
}

这种事情甚至严重到，如果在引入的依赖中，有人恶意将这样验证错误值进行修改的代码包含进去，将导致重大的安全问题：

1
2
3
4
import "cropto/rsa"
func init() {
	rsa.ErrVerification = nil
}

在硕大的代码依赖中，我们几乎无法保证这种恶意代码不会出现在某个依赖的包中。为了安全起见，变量错误类型可以修改为常量错误：

1
2
3
4
5
-var EOF = errors.New("EOF")
+const EOF = ioError("EOF")
+type ioEorror string
+
+func (e ioError) Error() string { return string(e) }

自定义错误

1
if err, ok := err.(SomeErrorType); ok { ... }

这类错误处理的方式通过自定义的错误类型来表示特定的错误，同样依赖上层代码对错误值进行检查，不同的是需要使用类型断言进行检查。例如：

1
2
3
4
5
6
7
8
type CustomizedError struct {
	Line int
	Msg  string
	File string
}
func (e CustomizedError) Error() string {
	return fmt.Sprintf("%s:%d: %s", e.File, e.Line, e.Msg)
}

这种错误处理的好处在于，可以将错误包装起来，提供更多的上下文信息，但错误的实现方必须向上层公开实现的错误类型，不可避免的同样需要产生依赖关系。

隐式错误

1
if err != nil { return err }

这种错误处理的方式直接返回错误的任何细节，直接将错误进一步报告给上层。这种情况下，错误在当前调用方这里完全没有进行任何加工，与没有进行处理几乎是等价的，这会产生的一个致命问题在于：丢失调用的上下文信息，如果某个错误连续向上层传播了多次，那么上层代码可能在输出某个错误时，根本无法判断该错误的错误信息究竟从哪儿传播而来。以上面提到的文件打开的例子为例，错误信息可能就只有一个 not found。

4.1.3 处理错误的本质

回顾处理错误的基本策略我们可以看出，在 Go 语言中错误处理这一话题基本上是围绕以下三个问题进行的：

错误值检查：如何对一个传播链条中的错误类型进行断言？
错误格式与上下文：出现错误时，没有足够的堆栈信息，如何增强错误发生时的上下文信息并合理格式化一个错误？
错误处理语义：每个返回错误的函数都要求调用方进行显式处理，处理方式啰嗦而冗长，如何减少这种代码出现的密集程度？

我们在后面的小节中对这些问题进行一一讨论。