Error Flows in Go

原文链接:Error Flows in Go

作者:Preslav Rachev

下面这篇文章是我在 2023 年写的一篇关于 Go 中错误处理的文章的后续。建议还没读过这篇文章的人先看看这篇文章。

您想过 Go 应用程序出错时会发生什么吗?从 Go 应用程序的角度来看,发生错误有三个不同点:

  1. 错误 "originates ,",即首次出现(例如,您最后一次实际使用 errors.New)。
  2. 我们控制下的函数捕捉到错误,并决定采取以下措施之一
  • 缩短代码执行时间(panic, early return, clean up)
  • 或者更常见的做法是,将捕获到的错误与某些上下文进行封装,并将其返回给链中的前一个调用者。
  1. 错误会 "冒泡 "到最外层的调用者。除非途中发生了特殊情况(例如有人惊慌失措),否则这通常是 main 包,甚至是 main 函数本身。这通常是尝试窥探错误的地方,但老实说,在 99% 的情况下,这部分都很简单:

    1. 写出完整的错误信息,以便调试。
    2. 根据情况决定错误是否严重到需要继续运行应用程序。也许最好直接杀死应用程序,让基础架构重新启动。例如,如果错误发生在 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"之类的词。

您可以查看我上一篇文章中的这一部分,以获得很好的说明。

相关推荐
醒过来摸鱼8 分钟前
【Golang】协程
开发语言·后端·golang
谷大羽13 分钟前
Kafka Stream实战教程
spring boot·后端·中间件·kafka·stream
2401_8576363920 分钟前
实验室管理平台:Spring Boot技术构建
java·spring boot·后端
一个小坑货1 小时前
Rust基础
开发语言·后端·rust
初晴~2 小时前
【Spring】RESTful设计风格
java·后端·spring·springboot·restful
H2Z20Str2 小时前
PIXHAWK(ardupilot4.52)单ic通道输出pwm
后端·restful
西域编娃2 小时前
Scala 编程实战:梦想清单管理器
开发语言·后端·scala
2401_871290582 小时前
Scala中的Array
开发语言·后端·scala
Object~2 小时前
【第九课】Rust中泛型和特质
开发语言·后端·rust
郑祎亦3 小时前
JavaWeb开发:HTML 页面与接口对接
前端·后端·java-ee·html