はなぜ 'Submissions.Where（S =>（偽&& s.Status == Convert.ToInt16（ ""）））' FormatExceptionを上げますか？

Question

それにもかかわらず（「入力文字列が正しい形式ではありませんでした」）私は、クエリはかなり些細だと思ったが、それはFormatExceptionを上げています：

Submissions.Where(s => (false && s.Status == Convert.ToInt16(""))) 

（もちろん、私のコードでは、 'に評価し、別の式偽& &」の前にある 『『）

なぜあるの後の部分』& &』最初の部分は常に偽であり、合計式はtrueに評価ことはできませんので、評価しますか？唯一Convert.ToInt16("")部分は例外を発生させるように見えるので、

状況は特に奇妙である -

Submissions.Where(s => (false && s.SubmissionDate <= DateTime.Now)) 

よう多かれ少なかれ同じ構造の私の元のクエリの他の部分は、正しく評価されています。

Answer 1

他の人が指摘しているように、LINQ to SQLコードは、データベースに対してSQLコードとして実行される前に、式ツリーに分離されています。 SQLは必ずしもC＃と同じ短絡ブール規則に従うわけではないので、式コードの右側が解析されてSQLが構築される可能性があります。 MSDNから

：

C＃が 論理演算子& &と||のオペランドの辞書順に基づいて短絡セマンティクス を指定します。 上のSQLは セットベースのクエリを対象としているため、 は オプティマイザが の実行順序を決定する自由度が増します。

このコードで例外が発生する理由は、Convert.ToInt16("")は、空の文字列を整数に変換する方法がないため、常にその例外をスローします。他の例では無効な変換は行われないため、問題なく実行されます。

Answer 2

SubmissionsがIQueryable<T>の場合、通常のC＃デリゲートではありませんが、式ツリーです。いくつかのコード（LINQプロバイダ）は、このツリーを分離して理解しなければなりません。式に奇妙な点がある場合は、奇妙な出力を期待してください。コメントでまあ私の質問へのご回答に基づいて

Answer 3

それはLINQ to SQLのだから、それは実際にはデリゲートではありません。私はオブジェクトにLinqを使ってそれを作り直してみましたが、確かに問題は全くありませんでした。 VSは実際には「到達不能コードが検出されました」と指摘しました。あなたのケースでは、それは実際にLinq to Sqlなので、式ツリーを構築しています。その場合は、すべてを解読してすべてのベットがオフになっています。

Answer 4

提案：（「」）Convert.ToInt16の結果を保持する静的Int16型を使用し、次に述語スタティックを指します。

より良いまだ、あなたはConvert.ToInt16（「」）の結果が何であるかを知っているのですか？はい？それを代わりに使用してください。たとえば、0ならば、s.Status == 0と言うことができます。それを定数にすることさえできます。