通过消除错误消除错误处理

Code talks

2019-02-06

go, translation

本文译自 Eliminate error handling by eliminating errors 版权@归原文所有.

Go 2 旨在改善错误处理的开销, 但是你知道有什么比处理错误的改进语法更好吗? 根本不需要处理错误. 现在, 我不是说 “删除你的错误处理代码”, 相反我建议改变你的代码, 这样你就没有多少错误需要处理.

本文从 John Ousterhout 软件设计的哲学的一章中汲取灵感, “定义不存在的错误”. 我尝试将他的建议应用于 Go.

这是一个计算文件行数的函数:

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 方法, 递增计数器直到我们到达文件的末尾, 然后我们返回读取的行数. 这是我们想编写的代码, 而 CountLines 因错误处理而变得更加复杂.

例如, 有这种奇怪的结构:

 _, err = br.ReadString('\n')
lines++
if err != nil {
        break
}

我们在检查错误之前增加行数, 这看起来很奇怪. 我们必须以这种方式编写它的原因是, 如果在遇到换行符之前遇到文件结尾-io.EOF, 则 ReadString 将返回错误. 如果没有尾换行符, 则会发生这种情况.

为了定位这个问题, 我们重整逻辑以增加行数, 然后查看是否需要退出循环.

但是我们还没有完成错误检查. 当 ReadString 到达文件末尾时, 它将返回 io.EOF. 这是预期的, ReadString 需要某种方式来终止, 没有更多内容需要读取. 所以在我们将错误返回给 CountLine 的调用者之前, 我们需要检查错误是不是 io.EOF, 并且在这种情况下将其传递, 否则我们返回 nil 表示一切正常. 这就是为什么函数的最后一行不是简单的:

return lines, err

我认为这是 Russ Cox 错误的处理可能会模糊函数操作的一个很好的例子. 我们来看一个改进的版本:

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 添加一层抽象, 这有助于消除掩盖我们之前版本的 CountLines 的操作的错误处理.

如果扫描器匹配了一行文本并且没有遇到错误, 则 sc.Scan() 方法返回 true. 因此, 只有当扫描器的缓冲区中有一行文本时, 才会调用 for 循环体. 这意味着我们修改后的 CountLines 正确处理了没有尾换行符的情况, 它还正确处理了文件为空的情况.

其次, 当 sc.Scan 遇到错误时返回 false, 当到达文件结尾或遇到错误时, 我们的 for 循环将退出. bufio.Scanner 类型会记住遇到的第一个错误, 一旦我们使用 sc.Err() 方法退出循环, 我们就恢复该错误.

最后, buffo.Scanner 负责处理 io.EOF 并在到文件末尾时将其转换为 nil, 而不会遇到其他错误.

我的第二个例子的灵感来自于 Rob Pike 的错误是值的博客文章.

在处理打开, 写入和关闭文件时, 错误处理存在但不是压倒性的, 因为操作可以封装在诸如 ioutil.ReadFile 和 ioutil.WriteFile 之类的帮助程序中. 但是, 在处理低级网络协议时, 通常需要使用 I/O 原语直接构建响应, 因此错误处理可能变得重复. 考虑构建 HTTP/1.1 响应的 HTTP 服务器的这个片段:

type Header struct {
        Key, Value string
}

type Status struct {
        Code   int
        Reason string
}

func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error {
        _, err := fmt.Fprintf(w, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason)
        if err != nil {
                return err
        }
        
        for _, h := range headers {
                _, err := fmt.Fprintf(w, "%s: %s\r\n", h.Key, h.Value)
                if err != nil {
                        return err
                }
        }

        if _, err := fmt.Fprint(w, "\r\n"); err != nil {
                return err
        } 

        _, err = io.Copy(w, body) 
        return err
}

首先, 我们使用 fmt.Fprintf 构造状态行, 并检查错误. 然后对于每个头, 我们写入键和值, 每次都检查错误. 最后, 我们使用额外的 \r\n 终止头部分, 检查错误, 并将响应体复制到客户端. 最后, 虽然我们不需要检查来自 io.Copy 的错误, 但我们需要将它从 io.Copy 返回的两个返回值形式转换为 WriteResponse 期望的单个返回值.

这不仅是大量的重复工作, 每个操作 - 从根本上将字节写入 io.Writer - 具有不同形式的错误处理. 但是我们可以通过引入一个小包装类型来变得容易:

type errWriter struct {
        io.Writer
        err error
}

func (e *errWriter) Write(buf []byte) (int, error) {
        if e.err != nil {
                return 0, e.err
        }

        var n int
        n, e.err = e.Writer.Write(buf)
        return n, nil
}

errWriter 实现了 io.Writer 接口, 所以可以用它来包装现有的 io.Writer. errWriter 将写入传递给其底层写入器(writer), 直到检测到错误. 从那起, 它会丢弃任何写入并返回先前的错误.

func WriteResponse(w io.Writer, st Status, headers []Header, body io.Reader) error {
        ew := &errWriter{Writer: w} 
        fmt.Fprintf(ew, "HTTP/1.1 %d %s\r\n", st.Code, st.Reason)

        for _, h := range headers {
                fmt.Fprintf(ew, "%s: %s\r\n", h.Key, h.Value)
        }

        fmt.Fprint(ew, "\r\n")
        io.Copy(ew, body)

        return ew.err
}

将 errWriter 应用于 WriteResponse 可以显著提高代码的清晰度. 每个操作不再依附在一个错误处理块. 通过检查 ew.err 字段, 将错误报告移动到函数的末尾, 避免从 io.Copy 的返回值进行恼人的转换.

当你发现自己面临恼人的错误处理时, 请尝试将某些操作提取到帮助程序类型中.