Quando SqlCommand.ExecuteReader() restituisce null?

Question

Quando si utilizza il metodo SqlCommand.ExecuteReader(), ReSharper mi dice che ho una possibile eccezione NullReference quando utilizzo l'oggetto SqlDataReader in seguito.

Quindi, con il seguente codice:

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

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

La while (reader.Read()) linea è sottolineata.

La mia domanda è quando il lettore dovrebbe mai essere nullo? Non l'ho mai incontrato e la documentazione non dice che potrebbe essere. Dovrei controllare se è nullo o è sicuro ignorarlo?

E perché ReSharper potrebbe pensare che potrebbe essere nullo, quando ad esempio mi consente di utilizzare SqlCommand senza raccomandare che venga controllato per null? Suppongo che ci sia un attributo sul metodo ExecuteReader.

Answer 1

È un falso positivo.

Riflettendo su SqlDataReader.ExecuteReader, posso vedere che l'unico modo in cui il lettore viene restituito come null è se il metodo RunExecuteReader interno viene passato "false" per returnStream, che non lo è.

Nelle profondità della SqlDataReader, un costruttore lettore è sempre chiamato a un certo punto, quindi sono abbastanza sicuro che questo non è fisicamente possibile per ExecuteReader per restituire null.

Answer 2

Ho riscontrato questo problema in un paio di altre aree. Sembra che abbiano fatto un'analisi dei percorsi del codice nelle varie parti del CLR. Quando scoprono che è ipotizzabile restituire null, è quando si lamentano.

Nel caso particolare in cui mi sono lamentato, null non potrebbe effettivamente accadere. Tuttavia, hanno tracciato il grafo delle chiamate in un metodo che poteva restituire null, in alcune circostanze, e il valore nullo potrebbe teoricamente propagarsi in alto.

Quindi, lo chiamo un bug ReSharper (pensavo che in precedenza si chiamava un bug CLR).

Answer 3

Ho determinato una ragione per cui ExecuteReader() può restituire null.

Nel caso in cui stavo ottenendo un null, avevo inviato al mio client uno script per aggiornare una stored procedure. Il Sql Server (2000) del mio cliente è impostato in modo tale che gli utenti DB abbiano bisogno di un'autorizzazione per eseguire una stored procedure. Quando hanno aggiornato l'SP, il permesso è stato rimosso e non è stato nuovamente assegnato. In questo caso, SqlCommand.ExecuteReader() ha restituito un valore null.

Riassegnazione dell'autorizzazione risolta.

Answer 4

Ho avuto un problema in cui ho interrogato .dbo.sysfiles per i file di registro e ottenuto un null in cambio. Ho avuto il mio client connettersi come utente di sistema che era amministratore di sistema, non so cosa sia successo ...

Answer 5

Il programma di ricerca è corretto, può restituire nulla in potenziale.

Non importa se un'implementazione specifica per ExecuteReader() non consentirà di far apparire un valore nullo - resta il fatto che IDataReader è un oggetto che può contenere (o puntare a) null.

• E se in futuro decideste di utilizzare un'implementazione diversa di IDbCommand?
• E se il prossimo aggiornamento di quell'implementazione di IDbCommnd conterrà un flusso diverso nel codice che consentirà di creare un vuoto nullo?

non hai bisogno di sapere ciò che accade all'interno l'attuazione di un'interfaccia per utilizzare correttamente - hai solo bisogno di conoscere l'interfaccia, e in questo momento l'interfaccia permette nulla come valore di ritorno.