类似的做法在 Golang 标准库中屡见不鲜，让我们继续看看 Eliminate error handling by eliminating errors 中提到的一个关于 bufio.Reader 和 bufio.Scanner 的例子：
func CountLines(r io.Reader) (int, error) {
var (
br = bufio.NewReader(r)
lines int
err error
)
for {
_, err = br.ReadString('n')
lines++
if err != nil {
break
}
}
if err != io.EOF {
return 0, err
}
return lines, nil
}
我们构造一个 bufio.Reader，然后在一个循环中调用 ReadString 方法，如果读到文件结尾，那么 ReadString 会返回一个错误（io.EOF），为了判断此类情况，我们不得不在每次循环时判断「if err != nil」，看上去这是坏味道，改进版：
func CountLines(r io.Reader) (int, error) {
sc := bufio.NewScanner(r)
lines := 0
for sc.Scan() {
lines++
}
return lines, sc.Err()
}
实际上，和 bufio.Reader 相比，bufio.Scanner 是一个更高阶的类型，换句话简单点来说的话，相当于是 bufio.Scanner 抽象了 bufio.Reader，通过把低阶的 bufio.Reader 换成高阶的 bufio.Scanner，循环中不再需要判断「if err != nil」，因为 Scan 方法签名不再返回 error，而是返回 bool，当在循环里读到了文件结尾的时候，循环直接结束，如此一来，我们就可以统一在最后调用 Err 方法来判断成功还是失败，看看 Scanner 的定义：
type Scanner struct {
r io.Reader // The reader provided by the client.
split SplitFunc // The function to split the tokens.
maxTokenSize int // Maximum size of a token; modified by tests.
token []byte // Last token returned by split.
buf []byte // Buffer used as argument to split.
start int // First non-processed byte in buf.
end int // End of data in buf.
err error // Sticky error.
empties int // Count of successive empty tokens.
scanCalled bool // Scan has been called; buffer is in use.
done bool // Scan has finished.
}
可见 Scanner 封装了 io.Reader，并且封装了 error，和我们之前讨论的做法一致。有一点说明一下，实际上查看 Scan 源代码的话，你会发现它不是通过 err 来判断是否结束的，而是通过 done 来判断是否结束，这是因为 Scan 只有遇到文件结束的错误才退出，其它错误会继续执行，当然，这只是具体的细节问题，不影响我们的结论。
通过对以上几个例子的分析，我们可以得出优化重复错误处理的大概套路：通过创建新的类型来封装原本干脏活累活的旧类型，同时在新类型中封装 error，新旧类型的方法签名可以保持兼容，也可以不兼容，这个不是关键的，视客观情况而定，至于具体的逻辑实现，先判断有没有 error，如果有就直接退出，如果没有就继续执行，并且在执行过程中保存可能出现的 error 以便后面操作使用，最后通过统一调用新类型的 error 来完成错误处理。提醒一下，此方案的缺点是要到最后才能知道有没有错误，好在如此的控制粒度在多数时候并无大碍。
