Когда 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()) линия подчеркнута.

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

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

Answer 1

Это ложное срабатывание.

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

У меня возникла проблема: я запросил файлы журналов в .dbo.sysfiles и получил null взамен.Мой клиент подключился как пользователь СИСТЕМЫ, который был системным администратором, но не знаю, что произошло...