关于 Golang Go语言中不处理数据库操作的 error 的一点思考

事情的起因是这样的。一个方法要查询 N 次数据库，每一次查询都要 if err ，我实在受不了啦，思索一番后觉得似乎并不需要在运行时处理数据库操作的 error 。结论如下：

因为运行时的 error 大概率是连接，基建问题。如果是 sql 语句问题，早就该在测试环节就发现。既然是连接问题，那么一个查询报错，其它所有查询都会报错，所以在每一个查询的地方都做 err check 是没有意义的。

可是不处理 err 怎么知道数据库有问题呢，怎么保证业务的完整呢？我大概理出了三板斧：

query 的操作不处理 err ，sql 问题留到测试期解决
update, insert 类操作要处理 err, 保证数据安全
对这些操作做一层包装和封装，每次调用记录 error ，监控该报警报警

当然，我不确定我这个想法是否考虑周到，可能以偏概全了。欢迎大家一起讨论一下。

关于 Golang Go语言中不处理数据库操作的 error 的一点思考

更多关于关于 Golang Go语言中不处理数据库操作的 error 的一点思考的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

caililin 1楼•2 天前

不要忽略任何错误.哪怕打个日志也好. 用上模板写个 if err 也就一秒. 万一出问题帮你节省的时间起码几小时.

更多关于关于 Golang Go语言中不处理数据库操作的 error 的一点思考的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

eggper 2楼•2 天前

之前写 gorm 的时候，无查询结果时也会有 err 不知道现在是什么样了

itying888 3楼•2 天前

数据库查询错误，可能是数据库迁移没做好，这个测试环境可能无法复现（因为生产环境和测试环境很有可能用的不是同一个数据库，注意这里的错误不一定指的是某个表不存在，而是说可能出现一些异常数据导致查询错误）

gougou168 4楼•2 天前

必须要每个 error 都处理。

我就说一个最简单的场景,一个请求进来，判断是不是合法用户(根据 token 查询数据库中是否存在)，如果不存在，则在爬虫表里记录该请求的信息。
伪代码大概如下：

var count int64
err1 := dao.TestDb.Model(&dao.UserDao{}).Count(&count).Error
//用户信息表里没有，则记录爬虫
if count==0{
err2:= dao.TestDb.Create(userDao)
}

如果一个合法用户的请求进来，因为网络抖动出错了，也会导致 count=0 并且 err1 不为空,你没有处理 err1,所以后面 insert 成功了(你无法猜测网络波动的时间，只能尽可能的去处理所有的 error)。

vueper 5楼•2 天前

线上出现问题的时候，你就会后悔没有每个 err 都处理并打印日志了

songsunli 6楼•2 天前

写代码一时爽，查线上问题火葬场

yuanlaile 7楼•2 天前

goland 生产力搞起，输入
err.rr
按 tab
见证奇迹

zlyuanteng 8楼•2 天前

每个 err 都要处理，更何况设计到网络这种的

phonegap100 9楼•2 天前作者

很多因素会导致数据库报错，cpu 、内存、磁盘、其它慢 sql 影响、db 的定时任务、机器老化等。甚至使用的 orm 库可能有 bug ，导致某些正常连接有问题。建议还是每个错误都捕获，写 err 麻烦的话，goland 敲 err 然后直接 tab 键就自动补全了。

bupafengyu 10楼•2 天前

在 copilot 的帮助下, 没有太大问题.
考虑到费用问题, 也有很多免费的替代, 今天北大刚出了一款类似产品.

nodeper 11楼•2 天前

查线上问题的时候你把不得每行一条 log 。

sinazl 12楼•2 天前

能处理就处理，处理不了就抛出去，但是永远不要吞异常，

wuwangju 13楼•2 天前

一楼说的没错，你起码要打个 log ，不然线上出问题，找到你这你说不清楚这锅就得你背

songsunli 14楼•2 天前

First Last 查询 API 为单条查询设计，查询不到时会 ErrRecordNotFound 错误，使用 Take API 查询单条时，查询不到不会报错。应该是使用 API 的问题

phonegap100 15楼•2 天前作者

那可能是我对 Gorm 不熟悉的问题

songsunli 16楼•2 天前

没必要，err 该处理处理

htzhanglong 17楼•2 天前

还是打印日志为妙

caililin 18楼•2 天前

有一些 fail fast 的文档，这会儿时间不多，可以 Google 「 program design check error rare panic OR fail 」

h691938207 19楼•2 天前

其实 postgres 已经把错误日志收集了

htzhanglong 20楼•2 天前

谢谢你对测试的信任

zlyuanteng 21楼•2 天前

可以看下 Errors are values 这篇文章： https://go.dev/blog/errors-are-values

caililin 22楼•2 天前

db 的 error 你都敢不处理，胆子好大啊，链式操作怎么办？前一步操作失败该回滚了你还继续么
一个 crud 的接口，线上数据库字段变更没成功，查询操作失败了，抛个服务错误出来，你可以在网关加监控，捕捉到
现在 error 不处理了，等着客户投诉你你才知道啊，这么任性的么

ionicwang 23楼•2 天前

回滚？我目测 op 的数据库操作都没开启事物，回滚什么

gougou168 24楼•2 天前

对于数据库错误，我是直接 panic 出去了，事务内的会自动回滚，然后全局 recover 了特定于数据库的报错，提示给用户的就是数据库报错，日志里面记录了错误的详细信息

wuwangju 25楼•2 天前

首先写结论：必须处理 if err 判断，其实就是一个熟悉的过程，搞熟悉了就不介意了。就像菇凉一样，开始丑点，看顺了就好。

itying888 26楼•2 天前

是谁给了 op 这样的自信，哦，原来是因为懒和没经验，没被毒打过

phonegap100 27楼•2 天前作者

我是 if err != nill; panic(err); 然后在一个统一的地方全局处理，很多 err 确实属于没法处理，直接统一中断并且记录就好了，但是千万不要丢掉它。

ionicwang 28楼•2 天前

你是怎么目测出没用事务的？我是说 query 类操作不处理 err ，insert, update 要处理 err 。业务系统都是 query 多过 insert 和 update 。

htzhanglong 29楼•2 天前

我有提到，将数据库操作封装一层，统一记录 error 。

eggper 30楼•2 天前

你们都不看完内容吗，我说 insert 和 update 的处理 error ，这就覆盖了链式操作。

wuwangju 31楼•2 天前

这个提到了一个我没考虑到的场景，确实存在这个问题。不是单纯的查询不到的问题。我再犹豫一下。谢谢

wuwangju 32楼•2 天前

我补充一下：为什么我提出 query 类操作不处理 err ，我的考虑是这样的，
查询结果无非两种，是 struct 或者是 slice

一般来说，无论是什么查询结果，我们都会且有必要验证结果的有效性（而不仅仅是 err ）。
比如说：
1. 如果查询结果是一个 struct ，那么至少会 if xx != nil
2. 如果查询结果是一个 slice ，一般至少会判断 len(slice) > 0

在这两个前提下，无论有没有 err 都会去做的处理。（ for 类操作甚至不需要不需要提前 len(slice)）
重点：一旦发生 error, 那么这两种查询的结果一定是 nil 和 len(slice) = 0, 所以对于预期来说并没有任何差异。

htzhanglong 33楼•2 天前

并且，if err != nil 的判断并不能替代业务上的 if struct != nil or if len(slice) > 0 ，因为即使没有 error 发生。我从来不会以 error 有没有来判断数据正不正确。而是以数据本身判断数据是否正确。

伪代码如下：

var entity user
err := sqlx.Get(“select * from xx limit 1;”, &user)
if err != nil {
logger.Error(“xxxxxxxxxxxxxxxxxxxxx”);
return err
}

if user.ID == 0 {
return errors.New(“user not found”)
}

在这段代码中，重点只在与有没有写日志。有没有 if err 都不影响业务逻辑的流程。

那么，换个角度来说，是否所有数据库操作都可以统一写日志呢，业务中的 query 操作是否可以不显示处理 error 呢，单看这个例子似乎是可以的。

slice 查询操作场景你们也可以代入看看。

phonegap100 34楼•2 天前作者

这就不得不提 try…catch…的含金量了:)

h691938207 35楼•2 天前

要笑死搞到最后还是 java 的那一套 AOP 爽

bupafengyu 36楼•2 天前

#30 链式操作就不能 insert->query->update 么？
另外第二个问题你怎么办，查询出错不报错，前端显示空数据？
你要是用户，你上来看到报个错血压高，还是看上去自己的数据全没了血压高？

eggper 37楼•2 天前

你要是用户，你上来看到报个错血压高，还是看上去自己的数据全没了血压高？

----------------------------------------------------
这个你说得有些道理，我想想

bupafengyu 38楼•2 天前

还是一样的，go 的 sql 标准库也是这样。

caililin 39楼•2 天前

关于 Golang 中不处理数据库操作的 error 的一点思考，这是一个非常重要且值得深入探讨的话题。

在 Go 语言中，错误处理是通过返回 error 类型的值来实现的。对于数据库操作这种可能会失败的操作，正确的错误处理至关重要。不处理这些 error 可能会导致数据不一致、应用程序崩溃或其他严重的后果。

在实际开发中，我们经常会遇到一些开发者忽略或简化错误处理的情况。例如，他们可能只是简单地打印错误日志，而不采取任何恢复措施或向用户报告错误。这种做法虽然简单，但非常危险。

为了避免这种情况，我们应该始终对数据库操作的 error 进行妥善处理。具体来说，我们可以根据错误的类型采取不同的恢复策略，比如重试操作、回滚事务或向用户报告错误。同时，我们也可以使用一些辅助工具或库来简化错误处理的过程，比如使用上下文（context）来管理超时和取消操作，或者使用错误包装（error wrapping）来提供更详细的错误信息。

总之，在 Go 语言中处理数据库操作的 error 是一个非常重要的环节。我们不能因为追求代码的简洁性而忽略错误处理的重要性。相反，我们应该始终牢记错误处理的原则，并采取相应的措施来确保应用程序的稳定性和可靠性。只有这样，我们才能写出高质量的 Go 代码，为用户提供更好的服务。