Wann würde SqlCommand.ExecuteReader() null zurückgeben?

Question

Wenn ich die Methode SqlCommand.ExecuteReader() aufruft, sagt mir ReSharper, dass ich eine mögliche NullReference-Ausnahme habe, wenn ich das SqlDataReader-Objekt danach verwende.

Also mit dem folgenden Code:

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

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

Die while (reader.Read()) Linie ist unterstrichen.

Meine Frage ist, wann würde der Leser jemals null sein? Ich bin nie darauf gestoßen und die Dokumentation erwähnt nicht, dass es sein könnte. Sollte ich überprüfen, ob es null ist oder ist es sicher zu ignorieren?

Und warum sollte ReSharper denken, dass es null sein könnte, wenn ich zum Beispiel den SqlCommand verwenden kann, ohne zu empfehlen, es auf Null zu prüfen? Ich vermute, dass es ein Attribut für die ExecuteReader-Methode gibt.

Answer 1

Es ist eine falsche positive.

Nachdenken über SqlDataReader.ExecuteReader, kann ich sehen, dass die einzige Möglichkeit, den Leser als null zurückgegeben wird, ist, wenn die interne RunExecuteReader-Methode 'false' für ReturnStream übergeben wird, was nicht ist.

In den Tiefen von SqlDataReader, ein Reader-Konstruktor wird immer an einem bestimmten Punkt aufgerufen, ich bin mir ziemlich sicher, dass dies nicht physisch möglich ist, damit ExecuteReader null zurückgibt.

Answer 2

Ich hatte dieses Problem mit ihnen in ein paar anderen Bereichen. Es scheint, dass sie eine Analyse der Code-Pfade in den verschiedenen Teilen der CLR durchgeführt haben. Wenn sie feststellen, dass es denkbar ist, null zurückzugeben, dann beklagen sie sich darüber.

Im konkreten Fall habe ich mich darüber beschwert, null könnte eigentlich nicht passieren. Sie verfolgten jedoch das Aufrufdiagramm auf eine Methode, die unter bestimmten Umständen null zurückgeben konnte, und der Nullwert könnte sich möglicherweise nach oben ausbreiten.

Also, ich nenne es ein ReSharper-Bug (dachte ich früher nannte es einen CLR-Fehler).

Answer 3

Ich habe einen Grund festgestellt, warum ExecuteReader() null zurückgeben kann.

In dem Fall, in dem ich eine Null erhielt, hatte ich meinem Client ein Skript zum Aktualisieren einer gespeicherten Prozedur gesendet. Der Sql-Server (2000) meines Clients ist so eingerichtet, dass DB-Benutzer eine Berechtigung zum Ausführen einer gespeicherten Prozedur benötigen. Bei der Aktualisierung des SP wurde die Berechtigung entfernt und nicht neu zugewiesen. In diesem Fall hat SqlCommand.ExecuteReader() eine Null zurückgegeben.

Erneute Zuweisung der Berechtigung behoben dies.

Answer 4

Ich hatte ein Problem, wo ich .dbo.sysfiles für Log-Dateien abgefragt und bekam eine null im Gegenzug. Ich hatte meine Client-Verbindung als Systembenutzer, der war sysadmin, nicht sicher, was passiert ist ...

Answer 5

Resharper ist richtig, es kann Null im Potenzial zurückgeben.

Es spielt keine Rolle, ob eine spezifische Implementierung für ExecuteReader() es nicht erlaubt, einen Nullwert zu blasen - die Tatsache bleibt, dass IDataReader ein Objekt ist, das Null enthalten kann (oder auf Null zeigt).

• Was ist, wenn Sie sich in Zukunft für eine andere Implementierung von IDbCommand entscheiden?
• Was ist, wenn das nächste Update dieser IDbCommnd-Implementierung einen anderen Codefluss enthält, der es ermöglicht, null zu erzeugen?

Sie brauchen nicht zu wissen, was in der Implementierung einer Schnittstelle, um geschieht es richtig zu verwenden - Sie müssen nur die Schnittstelle kennen, und jetzt die Schnittstelle ermöglicht null als Rückgabewert.