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

При использовании вызова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.

Ответы на вопрос(5)

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

Повторное назначение разрешения исправило это.

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

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

What if in the future you decide to use a different implementation of IDbCommand? What if the next update of that IDbCommnd implementation will contain a different flow in the code which will allow to bubble up null?

You do not need to know what happens inside the implementation of an interface in order to use it correctly - вам просто нужно знать интерфейс, и сейчас интерфейс допускает нулевое значение в качестве возвращаемого значения.

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

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

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

Решение Вопроса

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

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

Ваш ответ на вопрос