永远不要使用Nulls？

Question

我们目前正在经历为C#编写一些编码标准的漫长过程.

我最近用签名写了一个方法

string GetUserSessionID(int UserID)

在未找到用户的会话的情况下,GetUserSession()返回null.

在我的通话代码中...我说...

string sessionID = GetUserSessionID(1)
if (null == sessionID && userIsAllowedToGetSession)
{
    session = GetNewUserSession(1);
}

在最近的一次代码审查中,审阅者说"你永远不应该从方法中返回null,因为它会在调用方法上花更多的工作来检查空值."

我立刻哭了恶作剧,好像你回来了字符串.空的你仍然需要对返回的值进行某种检查.

if (string.Empty == sessionID)

但是,考虑到这一点,我不会在Collection/Array/List的情况下返回null.我会返回一个空列表.

对此的解决方案(我认为)将重构为2种方法.

bool SessionExists(int userID);

和

string GetUserSessionID(int UserID);

这次,GetUserSessionID会抛出一个SessionNotFound异常(因为它不应该返回null)

现在代码看起来像......

if(!SessionExists(1) && userIsAllowedToGetSession))
{
   session = GetNewUserSession(1);
}
else
{
   session = GetUserSessionID(1);
}

现在这意味着没有空值,但对我来说这似乎有点复杂.这也是一个非常简单的例子,我想知道这将如何影响更复杂的方法.

关于何时抛出异常以及如何处理它们,有很多关于何时使用null的信息的最佳实践建议.

是否有其他人对空值的使用有任何可靠的指导(甚至更好的标准),这对可空类型意味着什么(我们应该使用它们吗？)

提前致谢,

克里斯.

=====

感谢大家!那里有很多有趣的讨论.

我已经给了egaga的答案,因为我喜欢将Get vs Find作为编码指南的建议,但所有这些都是有趣的答案.

Answer 1

nulls肯定比"魔术价值"更好,即更诚实.但是当发生错误时不应该返回它们 - 这就是例外情况.当谈到返回集合时......我更赞同空集合而不是空集合.

Answer 2

返回null很好,以下内容简洁易懂:

var session = GetUserSessionID(1) ?? GetNewUserSession(1);

Answer 3

可能的做法是对未在找到结果时抛出异常的方法使用get前缀,如果可能为null则使用find前缀.因此,在客户端很容易看到代码是否有问题处理null.

当然应该避免空值,Andrej Heljsberg在接受采访时表示,如果现在创建C#,它将有更好的方法来处理可空性.http://www.computerworld.com.au/article/261958/-z_programming_languages_c?pp=3&fp=&fpid=

Answer 4

在我看来,你不应该排除使用null作为返回值.我认为它在许多情况下都是有效的.但是你应该仔细考虑每种方法的专业人士和骗子.这完全取决于方法的目的和呼叫者的期望.

在您可能期望该方法不返回abject的情况下(即主键的数据库搜索,可能只返回一个实例或none/null),我个人会大量使用null返回值.如果可以正确地期望方法返回值,则应使用异常.

在您的特定示例中,我认为这取决于系统的上下文.如果实例的调用仅来自您可能期望登录用户的代码,则应该抛出异常.但是,如果没有用户登录,因此您没有要返回的会话ID,则应选择返回null.

Answer 5

为什么不使用Null设计模式呢？