调用方法时处理空对象

Question

我一直在寻找在调用方法（或方法链）时处理空对象的最佳选择。

我们通常的做法是检查 if 条件：

if ( customObject != null ) {
    customObject.callMe();
}

通过使用扩展方法可以进一步改进：

Program customObject = null;
if (customObject.NotNull()) {
    customObject.CallMe();
}

public static bool NotNull(this object o) {
    return o == null;
}

请注意：我通常忽略！来自我的编程实践。因此，明智的做法是说扩展方法对我来说很好。

但是，当涉及到方法链时，处理变得非常复杂。

customObject.CallMe().CallMe2() ex... 

您认为它可以在 C# 中如何处理，因此仅当 customObject 不为 null 时才调用 CallMe，并且仅当 CallMe 返回非 null 对象时才调用 CallMe2。

当然我可以使用 If 条件或三元运算符。但是，我想知道 vNext，C#5.0 是否有一些东西可以提供。

Answer 1

在即将到来的 C# 6 (vNext) 中，?. 运算符（Null Conditional Operator）允许您轻松地为每个嵌套属性链接空引用检查。

这方面的一个例子是：

int? first = customers?.[0].Orders?.Count();

这是 Visual Studio UserVoice 站点中请求的功能

Add ?. Operator to C#

您可以在 Roslyn 的 Codeplex 网站上查看 C# 6.0 的所有新语言功能的状态：

C# 6 Language Features Status

Answer 2

您目前可以编写这些类型的扩展方法：

public static class Extensions
{
    public static R IfNotNull<T, R>(this T @this, Func<T, R> @select) where T : class
    {
        return @this.IfNotNull(@select, () => default(R));
    }

    public static R IfNotNull<T, R>(this T @this, Func<T, R> @select, Func<R> @default) where T : class
    {
        return @this != null ? @select(@this) : @default();
    }

    public static void IfNotNull<T>(this T @this, Action<T> @action) where T : class
    {
        if (@this != null)
        {
            @action(@this);
        }
    }
}

然后这样称呼他们：

customObject 
    .IfNotNull(y => y.CallMe())
    .IfNotNull(y => y.CallMe2());

Answer 3

C# 5 无法简化您的代码。你被困在其中之一：

• 嵌套 if 条件
• 复杂的三元表达式
• Englobing try/catch 捕捉 NullReferenceException（如果你的链中的 null 不是真正的异常，你真的不应该这样做，即它不应该发生，但你想要一个 keepsafe）。

但是，作为空传播运算符 ?，未来可能会更加光明。是 C# 6 的一个提议的特性，并且有 already be implemented is Roslyn，所以如果它在 C# 6 中没有有效，那将是一个很大的惊喜。有了这个运算符，您将能够编写

customObject?.CallMe()?.CallMe2()?.[...] 

并且编译器会为你创建嵌套的 if（甚至确保每个方法只被调用一次）。所以，多一点耐心……

Answer 4

C# 6 确实有 ? 运算符，否则您可以查看 monad，尤其是 Maybe monad，例如here，here，elsewhere。是否值得在设计时没有考虑到它们的非函数式语言中使用 monad 是另一个问题。

Answer 5

由于人们正在撕毁假设您不是白痴的答案，因此这里假设您是白痴。

您应该检查customObject 的创建时间，因为您会知道为什么会得到一个空值。如果你当时没有检查，现在最好的办法是让你的代码抛出异常。如果在没有明确需要的对象的情况下仍然可以做一些完全有意义的事情，您可以在异常的 catch 中修复它，但可能没有。

所有忽略意外空值重要性的机制只是传递了之前没有注意的失败，包括习惯性地过度使用所提出的空值传播运算符，以及所有在使用前检查对象的习惯。他们正在寻求对灾难的有效反应，以尽量减少对灾难的关注。

如果你用一个对象的空值表示重要信息，那可能是一个糟糕的设计选择，你应该在引入空值时将它转换为更有用的信息。

在对象被使用之前而不是在它产生之后测试它的意外空值并不能真正帮助任何人。这是一种代码气味，表明您错位了责任，可能是以下方式之一：

1. 你不愿意挑战那些在没有充分解释的情况下做出尴尬的设计决策的人
2. 您觉得自己无法控制已合并的内容，但又懒得包装它
3. 您认为 null 不应该存在，并且您试图忽略它们，因此您没有考虑过任何关于它们的政策。

您指出的策略，即吃掉 null 并继续执行而不分析它，是一个糟糕的策略。如果您打算保留它，那是我的另一个答案。你应该做一些合理的事情。

在许多工作场所，在任何地方放置一个空的 catch 块是对未来工作的清晰记录。所以它正在做某事。但是离开它永远不会有一个适合好的代码的选项。这样的块将更合理地将异常转换为响应，从而创建未来的工作来修复错误的根源，即使代码块实施了一种以更本地方式解决问题的变通方法。

Answer 6

这是异常处理的重点。如果您想响应异常情况，例如从函数返回意外的 null，则 catch NullReferenceException，并从那里。异常本身将停止进一步的调用，因此如果您只想完成这一切，请不要实施恢复代码。 我不认为这是一个合理的回应，这样的事情通常至少应该被记录下来。

try
{
    customObject.CallMe().CallMe2()
}
catch (NullReferenceException ex)
{
   /* save enough details to determine why you got an unexpected null */
}

不要使用异常处理来完成正常的编程任务，但不要过度避免它，通过检查每一个可能的意外事件，无论多么罕见。确定您的代码中可能出现的故障（您可以做任何事情），并在每个合理大小的块的末尾包含一个健康的 catch 列表。