我对 Go 的错误处理有哪些不满，以及我是如何处理的

写 Go 的人往往对它的错误处理模式有一定的看法。按不同的语言经验，人们可能有不同的习惯处理方法。这就是为什么我决定要写这篇文章，尽管有点固执己见，但我认为听取我的经验是有用的。我想要讲的主要问题是，很难去强制执行良好的错误处理实践，错误经常没有堆栈追踪，并且错误处理本身太冗长。不过，我已经看到了一些潜在的解决方案，或许能帮助解决一些问题。

与其他语言的快速比较

在 Go 中，所有的错误都是值。因为这点，相当多的函数最后会返回一个 error, 看起来像这样：

func (s *SomeStruct) Function() (string, error)

因此这导致调用代码通常会使用 if 语句来检查它们：

bytes, err := someStruct.Function()
if err != nil {
  // Process error
}

另外一种方法，是在其他语言中，如 Java、C#、Javascript、Objective C、Python 等使用的 try-catch 模式。如下你可以看到与先前的 Go 示例类似的 Java 代码，声明 throws 而不是返回 error：

public String function() throws Exception

它使用的是 try-catch 而不是 if err != nil：

try {
  String result = someObject.function()
  // continue logic
}
catch (Exception e) {
  // process exception
}

当然，还有其他的不同。例如，error 不会使你的程序崩溃，然而 Exception 会。还有其他的一些，在本篇中会专门提到这些。

实现集中式错误处理

退一步，让我们看看为什么要在一个集中的地方处理错误，以及如何做到。

大多数人或许会熟悉的一个例子是 web 服务 - 如果出现了一些未预料的的服务端错误，我们会生成一个 5xx 错误。在 Go 中，你或许会这么实现：

func init() {
    http.HandleFunc("/users", viewUsers)
    http.HandleFunc("/companies", viewCompanies)
}
func viewUsers(w http.ResponseWriter, r *http.Request) {
    user // some code
    if err := userTemplate.Execute(w, user); err != nil {
        http.Error(w, err.Error(), 500)
    }
}
func viewCompanies(w http.ResponseWriter, r *http.Request) {
    companies = // some code
    if err := companiesTemplate.Execute(w, companies); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

这并不是一个好的解决方案，因为我们不得不重复地在所有的处理函数中处理错误。为了能更好地维护，最好能在一处地方处理错误。幸运的是，在 Go 语言的官方博客中，Andrew Gerrand 提供了一个替代方法，可以完美地实现。我们可以创建一个处理错误的 Type：

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

这可以作为一个封装器来修饰我们的处理函数：

func init() {
    http.Handle("/users", appHandler(viewUsers))
    http.Handle("/companies", appHandler(viewCompanies))
}

接着我们需要做的是修改处理函数的签名来使它们返回 errors。这个方法很好，因为我们做到了 DRY 原则，并且没有重复使用不必要的代码 - 现在我们可以在单独一个地方返回默认错误了。

错误上下文

在先前的例子中，我们可能会收到许多潜在的错误，它们中的任何一个都可能在调用堆栈的许多环节中生成。这时候事情就变得棘手了。

为了演示这点，我们可以扩展我们的处理函数。它可能看上去像这样，因为模板执行并不是唯一一处会发生错误的地方：

func viewUsers(w http.ResponseWriter, r *http.Request) error {
    user, err := findUser(r.formValue("id")) 
    if err != nil {
      return err;
    }
    return userTemplate.Execute(w, user);
}

调用链可能会相当深，在整个过程中，各种错误可能在不同的地方实例化。Russ Cox的这篇文章解释了如何避免遇到太多这类问题的最佳实践：

“在 Go 中错误报告的部分约定是函数包含相关的上下文，包括正在尝试的操作（比如函数名和它的参数）。”

这个给出的例子是对 OS 包的一个调用：

err := os.Remove("/tmp/nonexist")
fmt.Println(err)

它会输出：

remove /tmp/nonexist: no such file or directory

总结一下，执行后，输出的是被调用的函数、给定的参数、特定的出错信息。当在其他语言中创建一个 Exception 消息时，你也可以遵循这个实践。如果我们在 viewUsers 处理中坚持这点，那么几乎总是能明确错误的原因。

问题来自于那些不遵循这个最佳实践的人，并且你经常会在第三方的 Go 库中看到这些消息：

Oh no I broke

这没什么帮助 - 你无法了解上下文，这使得调试很困难。更糟糕的是，当这些错误被忽略或返回时，这些错误会被备份到堆栈中，直到它们被处理为止：

if err != nil {
  return err
}

这意味着错误何时发生并没有被传递出来。

应该注意的是，所有这些错误都可以在 Exception 驱动的模型中发生 - 糟糕的错误信息、隐藏异常等。那么为什么我认为该模型更有用？

即便我们在处理一个糟糕的异常消息，我们仍然能够了解它发生在调用堆栈中什么地方。因为堆栈跟踪，这引发了一些我对 Go 不了解的部分 - 你知道 Go 的 panic 包含了堆栈追踪，但是 error 没有。我推测可能是 panic 会使你的程序崩溃，因此需要一个堆栈追踪，而处理错误并不会，因为它会假定你在它发生的地方做一些事。

所以让我们回到之前的例子 - 一个有糟糕错误信息的第三方库，它只是输出了调用链。你认为调试会更容易吗？

panic: Oh no I broke
[signal 声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com