-
我的函数明明返回了一个 nil 的错误指针,调用方 if err != nil 却判定它不为 nil 进了错误分支,我对着 Go 里 nil 指针赋给接口后接口不等于 nil 这个坑排查了大半天的复盘
一个让我对 Go 的 interface 从以为懂到真正懂的烧脑坑,诡异到我一度怀疑 == 坏了:我返回的明明是 nil,调用方判断 != nil 却不是 nil。写了个返回 error 的函数,习惯性先声明具体错误类型指针 var e *MyError = nil,没出错时它保持 nil,最后 return e。传 true 不出错、e 一直是 nil,可调用方 if err != nil 却成…- 0
- 0
-
我的 Go 函数明明在成功时返回了 nil,调用方的 if err != nil 却死活为真,把成功请求全当失败处理,我对着这个见鬼的判断查了大半天的深度复盘
我写了个数据校验函数返回 error:通过返回 nil,失败返回自定义错误。可上线后明明校验通过、函数也 return 了"空"错误,调用方的 if err != nil 却死活为真,成功请求全被当失败处理。我写了最小复现:函数返回那个"nil",调用方打印 err == nil 竟是 false,而打印 err 又显示 。深挖才懂:我返回的是 *MyErr…- 0
- 0
-
返回 nil 却判定非 nil:Go nil 接口陷阱避坑
有个 Go 服务某接口偶发返回处理失败,可日志里找不到任何真正的错误——业务逻辑明明跑成功了数据也对,它就是固执地走进出错分支。我盯着那段再标准不过的代码看半天:err := doSomething(); if err != nil { return err },逻辑清清楚楚、doSomething 内部确认成功返回的是 nil,可那个 if err != nil 偏偏判定为真。一个等于 nil …- 4
- 0
typed nil
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×