SqlCommand.ExecuteReader（）はいつnullを返しますか？

Question

SqlCommand.ExecuteReader()メソッドを呼び出すと、ReSharperは、後でSqlDataReaderオブジェクトを使用するとNullReference例外が発生する可能性があることを示します。

using (SqlConnection connection = GetConnection()) 
{ 
    using (SqlCommand cmd = connection.CreateCommand()) 
    { 
     cmd.CommandText = ; //snip 

     using (SqlDataReader reader = cmd.ExecuteReader()) 
     { 
      while (reader.Read()) 
      { 
       //snip 
      } 
     } 
    } 
} 

while (reader.Read())行には下線が引かれます。次のコードでそう

。

私の質問は、読者オブジェクトがいつnullになるのですか？私はそれに遭遇したことはありませんし、ドキュメンテーションにはそれができると言及されていません。それがヌルか無視するのが安全かどうかチェックしなければなりませんか？

なぜ、ReSharperはnullになる可能性があると思いますか？たとえば、SqlCommandを使用してnullをチェックすることを推奨しない場合私は、ExecuteReaderメソッドに属性があると思います。

Answer 1

偽陽性です。

SqlDataReader.ExecuteReaderを参照すると、内部RunExecuteReaderメソッドがreturnStreamに 'false'が渡された場合、リーダーがnullとして返される唯一の方法であることがわかります。

SqlDataReaderの深さでは、リーダーコンストラクタは常にある時点で呼び出されるため、実際にはExecuteReaderがnullを返すことは物理的に不可能であるとは確信しています。

Answer 2

私は他のいくつかの分野でこの問題を抱えていました。 CLRのさまざまな部分でコードパスを分析したようです。彼らがヌルを返すことが考えられるとき、それは彼らがそれについて不平を言う時です。

私が訴えた特別なケースでは、nullは実際には起こり得ませんでした。しかし、コールグラフは、状況によってはnullを返す可能性のあるメソッドにトレースされ、null値はおそらくトップに伝播する可能性があります。

私はそれをReSharperのバグと呼びます（以前はCLRバグと呼ばれていたと思いました）。

Answer 3

私はExecuteReader（）がnullを返すことができる理由の1つを決めました。

私がnullを取得した場合、クライアントにストアドプロシージャを更新するためのスクリプトを送っていました。私のクライアントのSql Server（2000）は、DBユーザーがストアドプロシージャを実行するための権限を必要とするように設定されています。彼らがSPを更新したとき、許可は取り除かれ、再割り当てされませんでした。この例では、SqlCommand.ExecuteReader（）がnullを返しました。

許可を再割り当てするとこれが修正されました。

Answer 4

私はログファイルのために.dbo.sysfilesを問い合わせて、nullを受け取りました。 私のクライアントは、システム管理者だったSYSTEMユーザーとして接続しましたが、何が起こったのかわかりません...

Answer 5

Resharperは正しいです。

ExecuteReader()の特定の実装ではnull値をバブルアップできないかどうかは関係ありません。実際には、IDataReaderはnullを含む（または指す）ことができるオブジェクトです。

• 今後、別の実装IDbCommandを使用する場合はどうなりますか？
• そのIDbCommnd実装の次回の更新で、コード内にnullをバブルアップできる別のフローが含まれる場合はどうなりますか？

あなたが正しくそれを使用するために、インタフェースの実装内部で何が起こるかを知っている必要はありません - あなただけのインターフェイスを知っている必要があり、そして今のインタフェースは、戻り値としてnullができます。