Em que SqlCommand.ExecuteReader () return null?

Question

Ao usar chamando o método SqlCommand.ExecuteReader(), ReSharper me diz que eu tenho uma possível exceção NullReference quando eu usar o objeto SqlDataReader depois.

Assim, com o seguinte código:

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

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

A linha de while (reader.Read()) é sublinhado.

A minha pergunta é quando seria o objeto leitor sempre ser nulo? Eu nunca se deparar com ela ea documentação não mencionar que ele poderia ser. Devo estar verificando se é nulo ou é seguro ignorar?

E por que ReSharper pensar que poderia ser nulo, quando, por exemplo deixa-me usar o SqlCommand sem recomendar que ser verificado para nulo? Estou acho que há um atributo no método ExecuteReader.

Answer 1

É um falso positivo.

Refletindo sobre SqlDataReader.ExecuteReader, eu posso ver que a única maneira que o leitor é retornado como nula é se o método RunExecuteReader interna é passado 'false' para returnStream, o que não é.

Nas profundezas do SqlDataReader, a construtor leitor é sempre chamado em algum momento, então eu tenho certeza que isso não é fisicamente possível para ExecuteReader como nulo retorno.

Answer 2

ReSharper está correta, ele pode retornar nulo em potencial.

Não importa se uma implementação específica para ExecuteReader() não vai permitir que a borbulhar um valor nulo -. Os restos fato de que IDataReader é um objeto que pode conter (ou ponto a) nulo

• E se no futuro você decidir usar uma implementação diferente de IDbCommand?
• E se a próxima atualização do que a implementação IDbCommnd irá conter um fluxo diferente no código que permitirá a borbulhar nulo?

Você não precisa saber o que acontece dentro da implementação de uma interface, a fim de usá-lo corretamente - você só precisa saber a interface, e agora a interface permite nulo como um valor de retorno .

Answer 3

Eu tive este problema com eles em um par de outras áreas. Parece que eles fizeram uma análise dos caminhos de código nas várias partes do CLR. Quando eles acham que é concebível para retornar null, que é quando eles se queixam sobre isso.

No caso particular eu me queixava, null não poderia realmente acontecer. No entanto, eles traçaram o gráfico de chamadas para baixo para um método que poderia retornar nulo, em algumas circunstâncias, eo valor nulo pode conseguir propagar para o topo.

Então, eu chamo-lhe um bug ReSharper (pensei que anteriormente chamou-lhe um bug CLR).

Answer 4

Eu determinei uma razão pela qual ExecuteReader () pode retornar nulo.

No caso em que eu estava ficando um nulo, eu tinha enviado o meu cliente um script para actualizar um procedimento armazenado. Meu cliente do SQL Server (2000) está configurado de forma que os usuários de banco de dados precisa de uma permissão para executar um procedimento armazenado. Quando eles atualizou o SP a permissão foi removido e não re-atribuído. Neste caso, o SqlCommand.ExecuteReader () retornou um nulo.

Re-atribuir a permissão fixo isso.

Answer 5

Eu tive um problema onde eu questionaram .dbo.sysfiles para arquivos de log e tem um null em troca. Eu tive o meu cliente de conexão como usuário do sistema que foi sysadmin, não tenho certeza o que aconteceu ...