Когда SqlCommand.ExecuteReader() возвращает null?

Question

При использовании метода SqlCommand.ExecuteReader() ReSharper сообщает мне, что у меня есть возможное исключение NullReference, когда я потом использую объект SqlDataReader.

Так со следующим кодом:

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

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

while (reader.Read()) линия подчеркнуты.

Вопрос в том, когда объект-читатель когда-либо был бы нулевым? Я никогда не сталкивался с этим, и в документации не упоминается, что это может быть. Должен ли я проверять, является ли он нулевым или безопасно ли игнорировать?

И почему бы ReSharper думать, что он может быть пустым, когда, например, он позволяет мне использовать SqlCommand, не рекомендуя его проверять на нуль? Я предполагаю, что есть атрибут метода ExecuteReader.

Answer 1

Это ложное позитв.

Отражая на SqlDataReader.ExecuteReader, я вижу, что единственный способ, которым читатель возвращается как null, - это если внутренний метод RunExecuteReader передан 'false' для returnStream, а это не так.

В глубине SqlDataReader, a Конструктор чтения всегда вызывается в какой-то момент, поэтому я уверен, что для ExecuteReader физически невозможно вернуть null.

Answer 2

У меня была проблема с ними в нескольких других областях. Кажется, они провели анализ путей кода в различных частях CLR. Когда они находят, что возможно вернуть нуль, вот тогда они жалуются на это.

В конкретном случае, о котором я жаловался, нуль на самом деле не может произойти. Тем не менее, они проследили график вызовов до метода, который в некоторых случаях мог бы возвращать значение null, и нулевое значение могло бы, вероятно, распространяться на вершину.

Итак, я называю это ошибкой ReSharper (думал, что я раньше называл это ошибкой CLR).

Answer 3

Я определил одну причину, по которой ExecuteReader() может вернуть значение null.

В случае, когда я получал нуль, я отправил клиенту сценарий для обновления хранимой процедуры. Сервер Sql моего клиента (2000) настроен так, чтобы пользователям БД требовалось разрешение на выполнение хранимой процедуры. Когда они обновили SP, разрешение было удалено и не было повторно назначено. В этом случае SqlCommand.ExecuteReader() возвращает null.

Повторное присвоение разрешения зафиксировано.

Answer 4

У меня была проблема, когда я запросил .dbo.sysfiles для лог-файлов и получил взамен null. У меня был мой клиент, подключившийся к пользователю SYSTEM, который был системным администратором, но не уверен, что произошло ...

Answer 5

Resharper верен, он может вернуть нулевой потенциал.

Не имеет значения, не будет ли конкретная реализация для ExecuteReader() порождать нулевое значение - факт остается фактом: объект IDataReader является объектом, который может содержать (или указывать) значение null.

• Что делать, если в будущем вы решите использовать другую реализацию IDbCommand?
• Что делать, если следующее обновление этой реализации IDbCommnd будет содержать другой поток в коде, который позволит пузыриться до нуля?

Вам не нужно знать, что происходит внутри реализации интерфейса для того, чтобы правильно использовать его - нужно просто знать интерфейс, и теперь интерфейс позволяет нуль в качестве возвращаемого значения.