5
o := orm.NewOrm()
_, err = o.QueryTable(&User{}).Filter("uid", uid).All(&res, cols...)这段代码如果数据为空时，err返回的是nil，为啥不是 orm.ErrNoRows？
Q
[beego]orm查询数据为空时， err返回的是nil，不是 orm.ErrNoRows
A
回答
0
在原始的sql.ErrNoRows里面，它只会在使用Scan方法的时候返回这个错误。因此在orm里面也基本保持了这个语义。如果你的需求是判断是否返回了结果，可以通过第一个参数是否为0来判断。
目前来说，保持已有的语义是可以的。
我在考虑，是否在所有查找不到结果集的时候都返回这个error。但是这个改动属于一种破坏性的改动。
它的破坏性在于，有一些场景之下，我们找不到数据不会被认为是一种错误，而是一个合理的事情。例如，常见的如果用户并未下任何订单，那么找不到订单就是合理的。
这只是一种从语义上的考量。毕竟本质上来说，返回ErrNoRows也说得过去。毕竟golang的error并不会阻断后续代码的执行。
7
你觉得呢？
4
既然存在orm.ErrNoRows ，在所有查找不到结果集的时候都返回这个error比较好，这样用orm时不会有歧义，不然有人会误以为查询时没数据就返回 orm.ErrNoRows ，用这条件做一些特殊逻辑处理，产生bug。
或者所有方法都去掉 orm.ErrNoRows 呢？
5
这是一个两难的问题，如果全部方法去掉这个错误，那么已有的代码如果检查这个错误的，就都会不兼容； 同样，如果之前没有返回的现在突然返回了，已有的代码也可能会崩掉。
4
确实，如果所有方法都去掉 orm.ErrNoRows ，代码在编译时就会报错，更方便调整，问题不会被带到生成环境。反之如果之前没有返回的现在突然返回了，编译时发现不了，问题会被带到生成环境。
3
如果要坚持向下兼容，就不能改了
5
两难啊！我其实倾向于全部返回ErrNoRows，就是怕被喷=。=