golang，获取一条记录，数据库找不到记录，是返回特殊的 error 还是返回 nil ， error 也返回 nill

[void1900]

golang ，获取一条记录，数据库找不到记录，是返回 error 还是 返回对象 nil ， error 也返回 nill

比如用用户 ID 获取用户资料

我是返回一个特殊的 error

func (* UserModel) GetUser(uid uint) user User, err error {
   ....
   return user, ErrorNotFound
}

还是返回 nil, nil

func (* UserModel) GetUser(uid uint) user *User, err error {
   ....
   return nil, nil
}

[raincious]

我觉得这种问题没什么好纠结的。

返回 error 是考虑到后面的过程能截获这个错误然后进行处理，而标记成 Must 的函数则是这个函数出现错误之后，程序完全没必要继续运行下去了。

GetUser 找不到记录的话，应该返回 nil 指针附带一个错误，指明发生了什么（比如是什么导致无法获取用户的，是没有记录，服务器挂了，服务器拒绝处理还是其他什么）。你可以参考 Google 在自己 AppEngine 系统上的实现：
https://cloud.google.com/appengine/docs/go/datastore/reference#variables

当 Datastore 尝试获取一个不存在的对象时，会返回 ErrNoSuchEntity 这个 error 。

[aphasia]

这个跟你业务场景，以及设计有关，建议用 2 ，否则给自己留坑，不信你试试
如果用 2 的话，可以在调用函数时区分出到底是同 db 交互失败，还是交互成功但却查询为空，可以在调用时区别地对待这两种结果……
不信你试试 1 ……

[julor]

查询结果为空，返回 not found ，与数据交互出现的无知，直接返回上级错误

[janxin]

@aphasia 这两种在区分功能上并没有区别吧

[darasion]

我认为，
如果系统其他部分可能会报错，比如数据库可能连接不上， cache 可能挂了什么的，那返回值就需要第二个 error 参数
如果系统其他部分根本不可能报错，就是一个普普通通的数据类型，没有跟其他系统交互，那么就没有第二个 error 返回，找不到就直接一个 nil 就好了， nil 本身就是找不到的意思，互为充分必要条件。
至于返回是否是 nil 的检查，我想应该适当的抛给上层逻辑来处理。具体情况具体分析。

[leedstyh]

我也纠结过，现在的做法是：

定义一个`UserNotFound`的空 User struct ，如果查询没有结果，就返回`UserNotFound, nil`。

给 User 这个 struct 定义一个`IsNil()`的方法，一般来说用户名不能为空，所以就根据用户名来判断这个 user 是不是存在

handler 里，如果`user.IsNil()`结果是 true ，就返回 404