如何避免 Linq 链接返回 null？

Question

我对代码契约和 linq 有疑问。我设法将问题范围缩小到以下代码示例。现在我被困住了。

public void SomeMethod()
{
    var list = new List<Question>();

    if (list.Take(5) == null) { }
    // resharper hints that condition can never be true

    if (list.ForPerson(12) == null) { }
    // resharper does not hint that condition can never be true
}

public static IQueryable<Question> ForPerson(this IQueryable<Question> source, int personId)
{
    if(source == null) throw new ArgumentNullException();

    return from q in source
           where q.PersonId == personId
           select q;
}

我的 linq 链出了什么问题？为什么 resharper 在分析 ForPerson 调用时不“抱怨”？

编辑：ForPerson方法的返回类型从字符串更改为IQueryable，这就是我的意思。 （我的错）

Answer 1

Reshaper 正确的是，Take 或 Skip 的结果永远不会为 null - 如果没有项目，则结果是 IEnumerable，其中没有元素。我认为要做你想做的事你应该检查Any。

var query = list.Take(5);
if (!query.Any())
{
    // Code here executes only if there were no items in the list.
}

但这个警告是如何发挥作用的呢？仅通过查看方法定义，Resharper 无法知道该方法永远不会返回 null，并且我假设它不会对方法主体进行反向工程来确定它永远不会返回 null。因此，我认为它已经被专门硬编码，并有一条规则指定 .NET 方法 Skip 和 Take 不返回 null。

当您编写自己的自定义方法时，Reflector 可以从接口对您的方法行为做出假设，但您的接口允许它返回 null。因此它不会发出警告。如果它分析方法主体，那么它可以看到 null 是不可能的，并且能够发出警告。但分析代码以确定其可能的行为是一项极其困难的任务，我怀疑红门是否愿意花钱来解决这个问题，因为他们可以在其他地方以更低的开发成本添加更多有用的功能。

确定布尔表达式是否可以返回true称为布尔可满足性问题，是一个 NP 难问题。

您希望 Resharper 确定通用方法体是否可以返回null。这是上述 NP 难问题的推广。任何工具都不可能在 100% 的情况下正确执行此操作。

Answer 2

if(source == null) throw new ArgumentNullException(); 

这不是代码契约方式，您的意思是：

Contract.Require(source != null);