引言

如果你编写过 Go 代码，你可能已经遇到过内置的 error 类型。Go 代码使用 error 值来表示异常状态。例如，当 os.Open 函数无法打开文件时，它会返回一个非 nil 的 error 值。

func Open(name string) (file *File, err error)

以下代码使用 os.Open 打开文件。如果发生错误，它会调用 log.Fatal 打印错误消息并停止。

f, err := os.Open("filename.ext")
if err != nil {
    log.Fatal(err)
}
// do something with the open *File f

仅仅了解 error 类型的这些知识，你就可以在 Go 中完成很多工作，但本文我们将仔细研究 error，并讨论 Go 中错误处理的一些良好实践。

错误类型

error 类型是一个接口类型。一个 error 变量表示任何可以将其自身描述为字符串的值。这是接口的声明

type error interface {
    Error() string
}

与所有内置类型一样，error 类型在宇宙块中是预声明的。

最常用的 error 实现是 errors 包的未导出 errorString 类型。

// errorString is a trivial implementation of error.
type errorString struct {
    s string
}

func (e *errorString) Error() string {
    return e.s
}

你可以使用 errors.New 函数构造其中一个值。它接受一个字符串，将其转换为 errors.errorString 并作为 error 值返回。

// New returns an error that formats as the given text.
func New(text string) error {
    return &errorString{text}
}

以下是你如何使用 errors.New

func Sqrt(f float64) (float64, error) {
    if f < 0 {
        return 0, errors.New("math: square root of negative number")
    }
    // implementation
}

调用者向 Sqrt 传递负参数时，会收到一个非 nil 的 error 值（其具体表示是一个 errors.errorString 值）。调用者可以通过调用 error 的 Error 方法或直接打印它来访问错误字符串（“math: square root of…”）

f, err := Sqrt(-1)
if err != nil {
    fmt.Println(err)
}

fmt 包通过调用 error 值的 Error() string 方法来格式化它。

错误实现有责任总结上下文。os.Open 返回的错误格式为“open /etc/passwd: permission denied”，而不仅仅是“permission denied”。我们的 Sqrt 返回的错误缺少有关无效参数的信息。

为了添加这些信息，一个有用的函数是 fmt 包的 Errorf。它根据 Printf 的规则格式化字符串，并将其作为由 errors.New 创建的 error 返回。

if f < 0 {
    return 0, fmt.Errorf("math: square root of negative number %g", f)
}

在许多情况下，fmt.Errorf 已经足够好，但由于 error 是一个接口，你可以使用任意数据结构作为错误值，以便调用者可以检查错误的详细信息。

例如，我们假设的调用者可能想要恢复传递给 Sqrt 的无效参数。我们可以通过定义一个新的错误实现而不是使用 errors.errorString 来实现这一点

type NegativeSqrtError float64

func (f NegativeSqrtError) Error() string {
    return fmt.Sprintf("math: square root of negative number %g", float64(f))
}

一个复杂的调用者可以使用类型断言来检查 NegativeSqrtError 并特别处理它，而那些仅仅将错误传递给 fmt.Println 或 log.Fatal 的调用者将看到行为没有变化。

再举一个例子，json 包指定了一个 SyntaxError 类型，当 json.Decode 函数在解析 JSON blob 时遇到语法错误时会返回该类型。

type SyntaxError struct {
    msg    string // description of error
    Offset int64  // error occurred after reading Offset bytes
}

func (e *SyntaxError) Error() string { return e.msg }

Offset 字段甚至没有在错误的默认格式中显示，但调用者可以使用它来为错误消息添加文件和行信息

if err := dec.Decode(&val); err != nil {
    if serr, ok := err.(*json.SyntaxError); ok {
        line, col := findLine(f, serr.Offset)
        return fmt.Errorf("%s:%d:%d: %v", f.Name(), line, col, err)
    }
    return err
}

（这是 Camlistore 项目中实际代码的略微简化版本。）

error 接口只要求一个 Error 方法；特定的错误实现可能还有其他方法。例如，net 包按照通常的约定返回 error 类型的错误，但有些错误实现具有 net.Error 接口定义的附加方法

package net

type Error interface {
    error
    Timeout() bool   // Is the error a timeout?
    Temporary() bool // Is the error temporary?
}

客户端代码可以使用类型断言测试 net.Error，然后区分瞬态网络错误和永久性错误。例如，网络爬虫在遇到临时错误时可能会休眠并重试，否则就放弃。

if nerr, ok := err.(net.Error); ok && nerr.Temporary() {
    time.Sleep(1e9)
    continue
}
if err != nil {
    log.Fatal(err)
}

简化重复的错误处理

在 Go 中，错误处理很重要。该语言的设计和约定鼓励你在错误发生的地方显式检查错误（这与在其他语言中抛出异常并有时捕获它们的约定不同）。在某些情况下，这会使 Go 代码变得冗长，但幸运的是，你可以使用一些技术来最大限度地减少重复的错误处理。

考虑一个带有 HTTP 处理程序的 App Engine 应用程序，该处理程序从数据存储中检索记录并使用模板对其进行格式化。

func init() {
    http.HandleFunc("/view", viewRecord)
}

func viewRecord(w http.ResponseWriter, r *http.Request) {
    c := appengine.NewContext(r)
    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
    record := new(Record)
    if err := datastore.Get(c, key, record); err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    if err := viewTemplate.Execute(w, record); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

此函数处理 datastore.Get 函数和 viewTemplate 的 Execute 方法返回的错误。在这两种情况下，它都向用户显示一个简单的错误消息，HTTP 状态码为 500（“内部服务器错误”）。这看起来是一个可管理的少量代码，但添加更多 HTTP 处理程序后，你很快就会发现许多相同的错误处理代码副本。

为了减少重复，我们可以定义自己的 HTTP appHandler 类型，其中包含一个 error 返回值

type appHandler func(http.ResponseWriter, *http.Request) error

然后我们可以将 viewRecord 函数更改为返回错误

func viewRecord(w http.ResponseWriter, r *http.Request) error {
    c := appengine.NewContext(r)
    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
    record := new(Record)
    if err := datastore.Get(c, key, record); err != nil {
        return err
    }
    return viewTemplate.Execute(w, record)
}

这比原始版本更简单，但 http 包不理解返回 error 的函数。为了解决这个问题，我们可以在 appHandler 上实现 http.Handler 接口的 ServeHTTP 方法

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if err := fn(w, r); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

ServeHTTP 方法调用 appHandler 函数并将返回的错误（如果有）显示给用户。请注意，该方法的接收器 fn 是一个函数。（Go 可以做到这一点！）该方法通过在表达式 fn(w, r) 中调用接收器来调用该函数。

现在，在 http 包中注册 viewRecord 时，我们使用 Handle 函数（而不是 HandleFunc），因为 appHandler 是一个 http.Handler（而不是一个 http.HandlerFunc）。

func init() {
    http.Handle("/view", appHandler(viewRecord))
}

有了这个基本的错误处理基础设施，我们可以使其更加用户友好。除了简单地显示错误字符串之外，最好向用户提供一个带有适当 HTTP 状态码的简单错误消息，同时将完整错误记录到 App Engine 开发人员控制台以进行调试。

为此，我们创建了一个包含 error 和其他一些字段的 appError 结构体

type appError struct {
    Error   error
    Message string
    Code    int
}

接下来，我们修改 appHandler 类型以返回 *appError 值

type appHandler func(http.ResponseWriter, *http.Request) *appError

（通常将错误的具体类型而不是 error 返回回来是一个错误，原因在Go FAQ中讨论过，但在这里这样做是正确的，因为 ServeHTTP 是唯一看到该值并使用其内容的地方。）

并使 appHandler 的 ServeHTTP 方法向用户显示 appError 的 Message，并带有正确的 HTTP 状态 Code，并将完整的 Error 记录到开发人员控制台

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if e := fn(w, r); e != nil { // e is *appError, not os.Error.
        c := appengine.NewContext(r)
        c.Errorf("%v", e.Error)
        http.Error(w, e.Message, e.Code)
    }
}

最后，我们将 viewRecord 更新为新的函数签名，并在遇到错误时返回更多上下文

func viewRecord(w http.ResponseWriter, r *http.Request) *appError {
    c := appengine.NewContext(r)
    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
    record := new(Record)
    if err := datastore.Get(c, key, record); err != nil {
        return &appError{err, "Record not found", 404}
    }
    if err := viewTemplate.Execute(w, record); err != nil {
        return &appError{err, "Can't display record", 500}
    }
    return nil
}

这个版本的 viewRecord 与原始版本长度相同，但现在每行都有特定的含义，并且我们提供了更友好的用户体验。

不止于此；我们可以进一步改进应用程序中的错误处理。一些想法

• 为错误处理程序提供一个漂亮的 HTML 模板，

• 当用户是管理员时，通过将堆栈跟踪写入 HTTP 响应来简化调试，

• 为 appError 编写一个构造函数，用于存储堆栈跟踪以方便调试，

• 从 appHandler 内部的 panic 中恢复，将错误记录到控制台为“严重”，同时告诉用户“发生了严重错误”。这是一个很好的做法，可以避免将用户暴露于因编程错误导致无法理解的错误消息。有关更多详细信息，请参阅Defer、Panic 和 Recover 一文。

结论

正确的错误处理是优秀软件的基本要求。通过采用本文中描述的技术，你应该能够编写更可靠、更简洁的 Go 代码。