LINQ where 子句中的数组元素导致运行时错误与编译时错误答案

【问题标题】：Array element in LINQ where clause causes run time error vs compile time errorLINQ where 子句中的数组元素导致运行时错误与编译时错误
【发布时间】：2013-07-15 18:47:01
【问题描述】：

我了解到您不能在 LINQ 的 where 子句中使用数组元素。例如：

Department department = db.Departments.Single(d => d.DepartmentID == teams[i].DepartmentID);

那失败了。但是，我很好奇为什么这在编译时没有被捕获？是否存在这样的情况，可以防止此类语句出现全面编译时错误？

【问题讨论】：

是的，LINQ to Objects（例如）。这样它就可以很好地工作了。
不一定相关，但会在解决此错误之前将teams[i].DepartmentID 移动到变量中吗？例如var departmentId = teams[i].DepartmentID 然后引用 departmentId 代替？
是的，这行得通。但如果您在各种数组上进行选择，它会很快变得冗长。

标签： c# .net linq entity-framework linq-to-entities

【解决方案1】：

它不会在编译时被捕获，因为它是完全有效的 C#。表达式被转换为适当的表达式树 - 它只是实体框架不支持的表达式树。不同的 LINQ 提供程序可能能够支持它。

C# 编译器对 LINQ 提供程序一无所知，也不应该知道。它知道的唯一相关方面是如何从 lambda 表达式构造表达式树、如何调用扩展方法以及如何使用查询表达式（此处未使用，但通常是 LINQ 的一部分）。

区分语言支持和库支持非常重要——尤其是在LINQ的情况下。

【讨论】：

嗯，您没有听说过一些用于 IQueryable 提供程序的编译后检查器吗？我认为这可能是一个不错的功能。还是大家觉得写单元测试就够了？
@nsinreal：如果它是“编译后检查器”，那么它不在编译时，是吗？根据定义，它是编译后的时间。是的，这样的东西可能很有用——但我个人会先看看集成测试。

【解决方案2】：

c# 编译器将该代码转换为有效的表达式树，而 LinqToEntities 查询翻译器直到运行时才有机会使用该树。

c# 编译器无法知道 LinqToEntities 查询翻译器的功能。

【讨论】：

【解决方案3】：

在编译时，C# 编译器只是试图让你的代码成为一个有效的表达式树，如果你的代码可以转换成一个有效的表达式树，它就永远不会给出编译时错误。在编译时，它永远不会检查数据是否到来，索引是否在范围内。但是在运行时，只有当您的代码尝试将数据加载到其中时，只有代码才会给出异常。由于您的代码是正确的并且可以形成表达式树，因此它不会给出任何错误，但在运行时当它试图查看数据时会引发异常。据我所知，您可能会得到索引超出范围异常。由于您使用了“teams[i].DepartmentID”，如果 team 的第 i 个值不包含任何部门，那么它会给您这个错误。如果您使用的是循环，则迭代循环直到 i-1。

【讨论】：