Schließt das Schließen eines FileStreams den StreamReader?

Im Wesentlichen ja. Sie müssen einen StreamReader nicht schließen. Wenn Sie das tun, wird nur der zugrunde liegende Stream geschlossen.

@Bruno macht einen guten Grund, den äußersten Wrapper zu schließen. Es empfiehlt sich, den äußersten Stream zu schließen und die zugrunde liegenden Streams zu schließen, um sicherzustellen, dass alle Ressourcen ordnungsgemäß freigegeben werden.

Vom Reflektor ...

Nein. Sie sollten stattdessen reader schließen. In der Praxis stellt dies möglicherweise kein Problem dar, aber die StreamReader könnte zusätzlichen Aufwand verursachen, der möglicherweise bereinigt werden muss. Sie sollten also immer den obersten Wrapper schließen.

Sie können auch die File.ReadAllText-Methode verwenden:

Sie müssen den StreamReader nicht schließen, da er keine nicht verwalteten Ressourcen besitzt. Das Schließen des FileStreams ist ausreichend. Sie können Ihren Code mit using wie folgt neu schreiben:

Wenn Sie Zweifel haben, ist es am besten, wenn Sie alle IDisposable-Objekte entsorgen, wenn Sie damit fertig sind.

Nein. Am besten schließen Sie sie in umgekehrter Reihenfolge, in der Sie sie geöffnet haben.

Es scheint mir, dass der beste Weg, dies zu tun, darin besteht, den FileStream nur selbst zu schließen. Es hat nicht implizit Kenntnis von allem, was in einer Ebene über sich selbst existiert, so dass es effektiv ein Fehler ist, etwas zu tun, was diese höheren Ebenen beeinflussen würde.

Nachdem das gesagt wurde, sollten die übergeordneten Konstrukte auch nicht axiomatisch etwas von einer darunterliegenden darunterliegenden Schicht annehmen, oder sollten sie dies tun, sollten sie dies explizit tun:

1) Wenn es aus einem vorhandenen Stream erstellt wurde, sollte das Konstrukt auf höherer Ebene geschlossen werden können UNABHÄNGIG des zugrundeliegenden Streams (effektiv nur Ressourcen entsorgt werden, die ihm zugewiesen wurden) verwenden) oder geschlossen INCLUDING der zugrunde liegende Stream. Dies sollten zwei verschiedene Funktionsaufrufe sein, zum Beispiel Close () und CloseSelf () (falls dies so implementiert werden sollte, dass es mit existierendem Code abwärtskompatibel ist).

2) Wenn es nicht aus einem vorhandenen Stream erstellt wurde (dh der Konstruktor musste den zugrunde liegenden Stream erstellen), sollte das Schließen des übergeordneten Konstrukts auch das Schließen des zugrunde liegenden Streams erzwingen, da in diesem Fall der Der zugrunde liegende Stream ist ein impliziter Teil des übergeordneten Konstrukts. In diesem Fall würde CloseSelf () einfach Close () aufrufen.

Es erscheint verschwenderisch, diese Klassen so zu implementieren, wie es gemacht wurde. Wenn Sie beabsichtigen, die gleiche Datei für (als Beispiel) serielle Eingabe und serielle Ausgabe zu verwenden, werden Sie vom System effektiv dazu gezwungen, sie als zwei verschiedene Entitäten zu behandeln, wenn Sie Zugriff auf die höhere Funktionalität der abgeleiteten Klassen erhalten möchten. Ihre Alternative besteht darin, sich an das Konstrukt auf niedrigerer Ebene zu halten und die Funktionalität auf höherer Ebene selbst zu implementieren - indem Sie Ihre eigenen speziellen Versionen von bereits vorhandenen Nachkommenklassen effektiv neu implementieren.

Wenn es wie oben beschrieben gemacht würde, wäre die typische Funktionalität so einfach zu implementieren wie es jetzt ist, aber für anspruchsvollere Anwendungen würde man die Fähigkeit behalten, eine einzige Sperre auf eine Datei zu setzen und sie nach Bedarf wiederzuverwenden wenn es erforderlich ist, anstatt die Sperre und alle zugehörigen Ressourcen aufzugeben und sie dann sofort neu zuzuordnen, wodurch dem System Overhead- und Speicherfragmentierung ohne gültigen Grund hinzugefügt wird.

Unter den bestehenden Bedingungen ist das Richtige jedoch klar. Es kann nicht angenommen werden, dass der FileStream irgendetwas über ein Objekt weiß, zu dem er gehört, daher müssen Sie das äußerste umschließende Konstrukt schließen. Dies gilt unabhängig davon, ob es so oder so funktioniert, wie Bruno et al. Angemerkt haben, und aus dem Grund, den sie gegeben haben - Kompatibilität. Himmelfahrt ist der Urgroßvater der hässlichsten Käfer.

Interessant ist, dass das Schließen eines StreamReaders oder Writers den Lese- / Schreibstatus des besitzenden FileStreams beeinflusst. Dies scheint zu bedeuten, dass Sie keinen StreamReader und dann keinen StreamWriter mit demselben Dateistream verwenden können.