函数应该返回null还是空对象？

Question

从函数返回数据时的最佳实践是什么。返回Null还是空对象更好？又为什么一个要比另一个做呢？考虑一下：public UserEntity GetUserById(Guid userId){     //Imagine some code here to access database.....     //Check if data was returned and return a null if none found     if (!DataExists)        return null;         //Should I be doing this here instead?         //return new UserEntity();       else        return existingUserEntity;}让我们假装将有此计划，将有与该GUID数据库中没有用户信息的有效案例。我可以想象在这种情况下抛出异常是不合适的？另外，我的印象是异常处理会损害性能。

Answer 1

返回null通常是最好的主意，如果你打算表示没有数据可用。

一个空的对象意味着数据已经返回，而返回null清楚地表明，什么也没有返回。

此外，如果您尝试访问对象中的成员，则返回null会导致null异常，这对于突出显示错误代码很有用-尝试不访问任何成员都是没有意义的。访问空对象的成员不会失败，这意味着错误可能会被发现。

Answer 2

这取决于哪种情况最适合您的情况。

是否有意义返回空值，例如：“没有这样的用户存在”？

还是创建默认用户有意义？这是很有道理的，当你可以安全地假设，如果用户不存在，调用代码打算为一个，当他们要求它存在。

或者是否有意义抛出一个异常（一拉“FileNotFound”）如果调用代码是要求苛刻的用户使用无效的ID？

但是，从关注点/ SRP的角度来看，前两个更正确。从技术上讲，第一个是最正确的（但仅凭一根头发）-GetUserById仅应负责一件事-获取用户。通过返回其他内容来处理自己的“用户不存在”的情况可能违反了SRP。分开检查- bool DoesUserExist(id)如果您确实选择引发异常，则比较合适。

基于下面的大量评论：如果这是API级设计问题，则此方法可能类似于“ OpenFile”或“ ReadEntireFile”。我们正在从某个存储库“打开”用户，并从结果数据中添加对象。在这种情况下，例外可能是适当的。可能不是，但可能是。

所有方法都是可以接受的-这取决于API /应用程序的较大上下文。

Answer 3

如果特定合同违约，则应该（仅）引发异常。

在您的特定示例中，基于已知ID询问UserEntity，这取决于事实（如果缺少（删除）用户）是预期情况。如果是这样，则返回，null但是如果不是预期的情况，则抛出异常。

请注意，如果调用该函数，UserEntity GetUserByName(string name)则可能不会抛出该异常，但返回null。在这两种情况下，返回一个空的UserEntity都是无济于事的。

对于字符串，数组和集合，情况通常是不同的。我记得一些准则形式的MS，方法应将其接受null为“空”列表，但返回零长度而不是的集合null。字符串也一样。请注意，您可以声明空数组：int[] arr = new int[0];