->find()时hidden/appen/visible 逻辑问题 about think-orm HOT 8 OPEN

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。
所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

from think-orm.

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。 所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

你没懂我的意思，我的意思是像select可以返回数组对象， find也一样返回， 就不要null了， 有些场景需要同步，反而觉得不统一

from think-orm.

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。 所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

当然find有个findOrEmpty方法， 我就觉得 直接用这个方法返回就行， 干嘛非要来个null？ 不解

如果能统一， 像是结果结果获取后的操作很会统一舒服， append/hidden这些， 那如果按现在这样，我还要判断一下是不是null， 如果按select来根本不需要判断数组是不是空

from think-orm.

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。 所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

当然find有个findOrEmpty方法， 我就觉得 直接用这个方法返回就行， 干嘛非要来个null？ 不解

如果能统一， 像是结果结果获取后的操作很会统一舒服， append/hidden这些， 那如果按现在这样，我还要判断一下是不是null， 如果按select来根本不需要判断数组是不是空

那append/hidden就可以给这个空对象追加/隐藏数据了，但是这个数据在数据库中是不存在的，那别的比如save/delete方法是不是会报错？会导致程序更加容易出现问题的，排查问题起来也非常麻烦

from think-orm.

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。 所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

当然find有个findOrEmpty方法， 我就觉得 直接用这个方法返回就行， 干嘛非要来个null？ 不解
如果能统一， 像是结果结果获取后的操作很会统一舒服， append/hidden这些， 那如果按现在这样，我还要判断一下是不是null， 如果按select来根本不需要判断数组是不是空

那append/hidden就可以给这个空对象追加/隐藏数据了，但是这个数据在数据库中是不存在的，那别的比如save/delete方法是不是会报错？会导致程序更加容易出现问题的，排查问题起来也非常麻烦

你的思维不要陷入一个死循环好不好？ 我在讨论框架逻辑， 你在说业务流程， 你能明白我在说什么吗
在append之前，框架对于空数据就跳过了！ select不就这么干的吗？

from think-orm.

find为空时本身就返回的null，你在null上面执行hidden方法肯定会报错，select为空是返回的一个空的数据集对象，这个数据集对象是有hidden方法的，只是执行之后会遍历数据集里面的对象依次执行hidden方法，数据集为空也就没有遍历 当然不会报错。 所以在find方法后需要自行判断是否为null，或者使用try catch捕获异常

当然find有个findOrEmpty方法， 我就觉得 直接用这个方法返回就行， 干嘛非要来个null？ 不解
如果能统一， 像是结果结果获取后的操作很会统一舒服， append/hidden这些， 那如果按现在这样，我还要判断一下是不是null， 如果按select来根本不需要判断数组是不是空

那append/hidden就可以给这个空对象追加/隐藏数据了，但是这个数据在数据库中是不存在的，那别的比如save/delete方法是不是会报错？会导致程序更加容易出现问题的，排查问题起来也非常麻烦

你的思维不要陷入一个死循环好不好？ 我在讨论框架逻辑， 你在说业务流程， 你能明白我在说什么吗 在append之前，框架对于空数据就跳过了！ select不就这么干的吗？

本身append/each这类方法就是对获取数据之后进行后操作，所以没数据 也就到不了这些方法这里

from think-orm.

你需要在业务上使用select代替find方法····

from think-orm.

你需要在业务上使用select代替find方法····

好了， 到此为止， 咱俩交流结束， 谈论的不是一个层面

from think-orm.