前言
go error 的显示处理事被吐槽的比较多的一个设计，主要是需要不断往上抛 error，会写一堆重复的代码，相比 try … catch 用起来可能没那么爽，以下是一个典型案例。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
type Person {
age *Age
sex *Sex
}
func (p *Person) Info() {
age, err := p.age.Get()
if err != nil {
return err
}
sex, err := p.sex.Get()
if err != nil {
return err
}
...
}
范式
哨兵模式
预定义 error 错误，例如：
1
var ErrInvalidUnreadByte = errors.New("bufio: invalid use of UnreadByte")
缺点：
- 无法包含更多的上下文信息
- 在两个包之间引入了源代码依赖，当你想判断 err == io.Errxxx 时，就必须引入 io 包
自定义错误（error types）
1
2
3
4
5
6
7
8
9
type MyError sruct {
code int
msg string
line int
}
func (m *MyError) Error() string {
return fmt.Sprintf("code:%d, msg: %s, line: %d", m.code, m.msg, m.line)
}
可以添加一些自定义的错误信息，错误更详实。但公共 API 里面依然不建议使用这种方式，因为在进行错误类型判断的时候依然存在包的强制依赖问题
非透明错误处理（Opaque errors）
1
2
3
// Opaque returns an error with the same error formatting as err
// but that does not match err and cannot be unwrapped.
func Opaque(err error) error
只返回错误而不假设其内容，代码和调用者之间的耦合最少，作为调用者只关心结果是成功还是失败，但有时候这有点不够，因为有些场景调用者需要关心错误类型，比如由于网络原因导致的调用失败需要重试，由于业务原因导致的失败无需重试（比如用户未认证等等）。不透明策略更推荐的是断言 error 实现的行为，而不是特定的类型或值，如下示例：
1
2
3
4
5
6
7
8
type temporary interface {
Temporary() bool
}
func IsTemporary(err error) bool {
te, ok := err.(temporary)
return ok && te.Temporary()
}
如此一来非透明解决包之间的非必要依赖问题，也不用关心具体的错误细节，基础库也可以对错误码就行更好的变更。
减少错误判断代码
通过在结构体里面预定义一个错误然后提前返回的方式，官方的 bufio 库就是这样处理的，下面是一个简单示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
type errWriter struct {
w io.Writer
err error
}
func (ew *errWriter) write(buf []byte) {
if ew.err != nil {
return
}
_, ew.err = ew.w.Write(buf)
}
// 使用时
ew := &errWriter{w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
return ew.err
}
