原文链接：Error Flows in Go
作者：Preslav Rachev
下面这篇文章是我在 2023 年写的一篇关于 Go 中错误处理的文章的后续。建议还没读过这篇文章的人先看看这篇文章。
您想过 Go 应用程序出错时会发生什么吗？从 Go 应用程序的角度来看，发生错误有三个不同点：
- 错误 "originates ,"，即首次出现（例如，您最后一次实际使用
errors.New）。 - 我们控制下的函数捕捉到错误，并决定采取以下措施之一
- 缩短代码执行时间（panic, early return, clean up）
- 或者更常见的做法是，将捕获到的错误与某些上下文进行封装，并将其返回给链中的前一个调用者。
-
错误会 "冒泡 "到最外层的调用者。除非途中发生了特殊情况（例如有人惊慌失措），否则这通常是
main包，甚至是main函数本身。这通常是尝试窥探错误的地方，但老实说，在 99% 的情况下，这部分都很简单：- 写出完整的错误信息，以便调试。
- 根据情况决定错误是否严重到需要继续运行应用程序。也许最好直接杀死应用程序，让基础架构重新启动。例如，如果错误发生在 HTTP 请求期间，这部分可能会向用户显示标准错误页面。但是，如果是在应用程序启动过程中发生的错误（例如，无法连接到数据库），我会直接
log.Fatal该错误，然后让基础架构设置按顺序重启服务。
根据经验，除非您正在构建一个库，否则您可能不会花很多时间为您的应用程序引入新的错误。与其他 Go 应用程序一样，你的应用程序要么直接使用标准库，要么依赖于使用标准库的程序库。因此，在使用文件或数据库连接时，处理现有错误的几率要远远高于应用程序需要凭空编造新错误的几率。
不信？看看 Kubernetes 代码库中
errors.New出现的次数与fmt.Error(f)出现的次数。多出两倍还多？
这就是我认为许多围棋开发者最大的误区。不，我说的不是这个：
go
if err != nil {
return err
}这简直毫无用处。我强调过用有用的上下文来包装所有错误的重要性，我仍然坚定地坚持这一点。我认为人们弄错的是上下文中的信息传递部分。我经常看到信息试图告诉我哪里出错了。相反，他们应该告诉我在事情搞砸之前他们试图做什么。
事实上，如果你们发现自己处于第 1 阶段，并返回了一个全新的错误，那么使用 "**** 出错了 "的说法是没有问题的：
go
return fmt.Errorf("DB failure: %w", err)但你上面的 10 位调用者也会这样做。最后，不幸的值班开发人员得到的信息是这样的：
vbnet
ERROR: DB failure: DB failure: DB failure: failed connecting to the DB: DB failure: "DB connection failed"一点帮助都没有。你为什么不换个说法，告诉我代码在失败前试图做什么？换句话说，如果你在第 2 步，不要使用 "s*** got wrong"的模式，而是使用信息量更大的 "做了什么什么"。每个人都知道，如果他们看到错误日志，那是因为出错了，所以他们会多次感谢你没有一次又一次地使用 "failed"之类的词。
您可以查看我上一篇文章中的这一部分，以获得很好的说明。