为什么lambda中的这个短路不工作？

为什么linq试图检查第二个表达式呢？

.Where(t => String.IsNullOrEmpty(someNullString) || t.SomeProperty >= Convert.ToDecimal(someNullstring)) 

通常的解决方法是什么？

更新：
当然，它是关于LINQ to SQL的。 它无法转换为SQL。

Answer 1

是.Where用于Table<> ？

如果是这样，那么在获取任何数据之前，它必须将LINQ转换为SQL，并且必须将string转换为decimal 。 它还没有尝试实际执行比较，它正在尝试构建检索数据所必需的构造。

Answer 2

这有帮助吗？

 .Where(t => String.IsNullOrEmpty(someNullString) || (t.SomeProperty >= Convert.ToDecimal(someNullstring))) 

注意到第二个条件周围的（）？ 我认为它不起作用，但总的来说我更喜欢把（）放在我的代码中的每个条件。 这样，编译器在编译代码时知道哪些部分属于一起，为短路评估准备…

Answer 3

我不能重现短路评估的任何问题……

我认为这评估如下：

 [CompilerGenerated] private static bool b__f(MyObject t) { return (String.IsNullOrEmpty(someNullString) || t.SomeProperty >= Convert.ToDecimal(someNullstring)); } 

短路在这里工作得很好。

我怀疑Enumerable中的其他元素将第一个条件（ String.IsNullOrEmpty(someNullString) ）评估为false。 你能证实一下吗？

提供更多代码，以便我们分析。

Answer 4

在可评估的任何范围内，您是否有变量t ？

您是否尝试过这样的括号：

 .Where(t => (String.IsNullOrEmpty(someNullString) || t.SomeProperty >= Convert.ToDecimal(someNullstring))) 

？

Answer 5

在||上有一个解决方法 （或）Linq中的C＃操作符，根据您的情况，您可以执行以下操作：

 .Where(t => t.SomeProperty >= Convert.ToDecimal(someNullstring ?? "0")) 

当然，这可能不是您在特定情况下需要的解决方案，但至少它提供了如何绕过错误的想法。