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

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

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

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

必须要每个 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)。

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

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

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

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

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

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

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

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

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

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

没必要，err 该处理处理

还是打印日志为妙

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

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

谢谢你对测试的信任

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@maotao456 并且，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 查询操作场景你们也可以代入看看。

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

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

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

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

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

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