¿Cuándo SqlCommand.ExecuteReader() devolverá nulo?

Question

Al usar llamar al método SqlCommand.ExecuteReader(), ReSharper me dice que tengo una posible excepción de NullReference cuando uso el objeto SqlDataReader después.

Así, con el siguiente código:

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

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

El while (reader.Read()) línea está subrayado.

Mi pregunta es cuando el objeto del lector alguna vez sería nulo? Nunca me he encontrado y la documentación no menciona que podría ser. ¿Debo verificar si es nulo o es seguro ignorarlo?

¿Y por qué ReSharper cree que podría ser nulo, cuando, por ejemplo, me permite usar el SqlCommand sin recomendarlo, se comprueba si no tiene nulo? Supongo que hay un atributo en el método ExecuteReader.

Answer 1

Es un falso positivo.

Reflexionando sobre SqlDataReader.ExecuteReader, puedo ver que la única forma en que el lector se devuelve como nulo es si el método interno RunExecuteReader se pasa 'falso' para returnStream, que no es.

En las profundidades de SqlDataReader, un lector constructor siempre se llama en algún momento, así que estoy bastante seguro de que esto no es físicamente posible para ExecuteReader para volver nula.

Answer 2

Tuve este problema con ellos en un par de otras áreas. Parece que han hecho un análisis de las rutas de código en las diversas partes de la CLR. Cuando se dan cuenta de que es concebible devolver el valor nulo, es entonces cuando se quejan de ello.

En el caso particular que me quejé, nulo en realidad no podría suceder. Sin embargo, rastrearon el gráfico de llamadas hasta un método que podría devolver nulo, en algunas circunstancias, y el valor nulo podría posiblemente propagarse a la parte superior.

Por lo tanto, lo llamo un error ReSharper (pensé que anteriormente lo llamaba un error CLR).

Answer 3

He determinado una razón por la cual ExecuteReader() puede devolver nulo.

En el caso en que obtenía un nulo, le había enviado a mi cliente una secuencia de comandos para actualizar un procedimiento almacenado. El servidor Sql (2000) de mi cliente está configurado para que los usuarios de bases de datos necesiten un permiso para ejecutar un procedimiento almacenado. Cuando actualizaron el SP, el permiso se eliminó y no se volvió a asignar. En este caso, SqlCommand.ExecuteReader() devolvió un valor nulo.

La reasignación del permiso solucionó esto.

Answer 4

Tuve un problema donde consulté .dbo.sysfiles para archivos de registro y obtuve un null a cambio. Hice que mi cliente se conectara como usuario de SYSTEM que era sysadmin, no estoy seguro de lo que pasó ...

Answer 5

Resharper es correcto, puede devolver un potencial nulo.

No importa si una implementación específica para ExecuteReader() no permitirá que aparezca un valor nulo: el hecho es que IDataReader es un objeto que puede contener (o señalar) nulo.

• ¿Qué pasa si en el futuro decide utilizar una implementación diferente de IDbCommand?
• ¿Qué sucede si la próxima actualización de esa implementación de IDbCommnd contendrá un flujo diferente en el código que permitirá que se rompa nulo?

que no es necesario saber lo que ocurre dentro de la implementación de una interfaz con el fin de utilizarlo correctamente - sólo tiene que saber la interfaz, y en este momento la interfaz permite nulo como valor de retorno.