Est-il nécessaire d'envelopper les StreamWriter dans un bloc using?

Il y A quelques jours j'ai posté un peu de code comme ceci:

StreamWriter writer = new StreamWriter(Response.OutputStream);
writer.WriteLine("col1,col2,col3");
writer.WriteLine("1,2,3");
writer.Close();
Response.End();

M'a dit qu'au lieu de cela je doit envelopper StreamWriter en utilisant le bloc dans le cas d'exceptions. Un tel changement permettrait de faire ressembler à ceci:

using(StreamWriter writer = new StreamWriter(Response.OutputStream))
{
    writer.WriteLine("col1,col2,col3");
    writer.WriteLine("1,2,3");
    writer.Close(); //not necessary I think... end of using block should close writer
}
Response.End();

Je ne suis pas sûr pourquoi c'est un changement de prix. Si une exception s'est produite sans l'utilisation de bloc, l'écrivain et la réponse serait toujours nettoyé, droit? Ce qui ne l'aide du bloc de gain de moi?

InformationsquelleAutor Eric | 2009-06-19

22

Nope le flux de rester ouverte dans le premier exemple, étant donné que l'erreur serait nier la clôture de il.

L'aide de l'opérateur forces de l'appel d'Dispose() qui est censé nettoyer l'objet et fermer toutes les connexions ouvertes quand il quitte le bloc.

InformationsquelleAutor kemiller2002
16

Je vais donner à l'opinion dissidente. La réponse à la question "Est-il nécessaire d'envelopper les StreamWriter dans un bloc using?" est en fait de Non. En fait, vous ne devrait pas appel Disposer sur un StreamWriter, parce que sa dispose est mal conçu et mal fait quelque chose de mal.

Le problème avec StreamWriter, c'est que, lorsque vous mettez au Rebut, il Dispose le flux sous-jacent. Si vous avez créé le StreamWriter avec un nom de fichier, et il a créé sa propre FileStream en interne, ce comportement serait tout à fait approprié. Mais si, comme ici, on a créé le StreamWriter avec un flux existant, alors ce comportement est absolument quelque Chose de Mal(tm). Mais il le fait quand même.

Ce type de Code ne fonctionne pas:
```
var stream = new MemoryStream();
using (var writer = new StreamWriter(stream)) { ... }
stream.Position = 0;
using (var reader = new StreamReader(stream)) { ... }
```
parce que quand le StreamWriter de using bloc Dispose le StreamWriter, qui à son tour jette le ruisseau. Ainsi, lorsque vous essayez de lire à partir du flux, vous obtenez ObjectDisposedException.

StreamWriter est une horrible violation de la "nettoyer votre propre désordre de la règle". Il essaye de nettoyer de quelqu'un d'autre désordre, s'ils voulaient ou non.

(Imaginez si vous avez essayé dans la vie réelle. Essayez d'expliquer aux flics pourquoi vous ont fait irruption dans la maison d'autrui et ont commencé à jeter tous leurs trucs dans la poubelle...)

Pour cette raison, je considère StreamWriter (et StreamReader, qui fait la même chose) pour être parmi les très peu de classes où "si elle met en œuvre IDisposable, vous devez Disposer d'appel" est erroné. Jamais appel Disposer sur un StreamWriter qui a été créé sur un flux de données existant. Appeler la méthode Flush() à la place.

Alors assurez-vous de nettoyer le Ruisseau quand vous devriez. (Comme Joe l'a souligné, ASP.NET dispose la Réponse.OutputStream pour vous, donc vous n'avez pas besoin de s'inquiéter à ce sujet ici.)

Avertissement: si vous ne Jetez pas le StreamWriter, alors vous ne besoin d'appeler la méthode Flush() lorsque vous avez terminé l'écriture. Sinon, vous auriez des données sont encore en cours de mis en mémoire tampon, qui n'a jamais fait pour le flux de sortie.

Ma règle pour StreamReader est, faire semblant de ne pas mettre en œuvre IDisposable. Juste le laisser aller lorsque vous avez terminé.

Ma règle pour StreamWriter, appelez Chasse où vous sinon on aurait appelé en Disposer. (Cela signifie que vous devez utiliser un try..finally au lieu d'un using.)
- "Ma règle pour StreamReader est, faire semblant de ne pas mettre en œuvre IDisposable" - mais pas si vous construit le StreamReader à l'aide d'un nom de fichier, comme c'est le propre du flux dans ce cas. Je suis en désaccord que StreamReader/Écrivain est mal conçu. Même si je comprends les problèmes que vous décrivez, tout le design est compromis et je pense que sur la balance le comportement est correct pour la plupart des cas d'utilisation. Assurez-vous dans votre exemple ci-dessus, vous avez maintenant à votre nid à l'aide de relevés, mais ce n'est pas une grosse affaire. Il y a un débat sur la responsabilité de l'élimination dans cette question: stackoverflow.com/questions/674879
- Votre anti-règle est trop forte. Il devrait l'être, ne l'appelez pas Jeter (et donc de ne pas mettre en œuvre à l'aide d'un bloc) sur StreamReader/StreamWriter, sauf si vous avez l'intention de fermer le flux sous-jacent. Peut-être que ce qui est nécessaire est quelque chose comme le CloseInput drapeau sur XmlReaderSettings, mais pour StreamReader à la place.
- Vrai. Ce qu'ils doit avez fait, si vous construisez un nom de fichier, le constructeur crée un flux de données et de Disposer ferme; mais, si vous construisez un flux, il n'a pas la fermer, parce que quelqu'un d'autre a la propriété.
- Si vous aimez obtus code? (sourire) Viennent sur. Si vous souhaitez fermer le Flux sous-jacent, puis fermez le Flux sous-jacent. Rendre votre code dire ce que tu veux dire.
- .Net 4.5 fixe cette surveillance, il permet maintenant vous avez également la possibilité de laisser le flux ouvert: msdn.microsoft.com/en-us/library/gg712853.aspx
InformationsquelleAutor Joe White
4

Emballage de la StreamWriter dans un using bloc est à peu près équivalent au code suivant:
```
StreamWriter writer;
try
{
    writer = new StreamWriter(Response.OutputStream);
    writer.WriteLine("col1,col2,col3");
    writer.WriteLine("1,2,3");
}
catch
{
    throw;
}
finally
{
    if (writer != null)
    {
        writer.Close();    
    }
}
```
Alors que vous pourriez très bien écrire ce code vous-même, c'est tellement plus facile de le mettre dans un bloc using.
- la fermeture de la StreamWriter sera clode le Respose.OutputStream ainsi. Juste un avertissement si vous trouvez que vous avez des données le client.
- Omettez simplement le catch() {} partie, il ne sert à rien et ne peut être source de confusion.
InformationsquelleAutor Fredrik Mörk
3

Si une exception se produit sans l'aide du bloc et tue le programme, vous serez à gauche avec openconnections. L'utilisation de bloc sera toujours fermer la connexion pour vous, semblables à si vous étiez à utiliser try{}catch{}finally{}
- Si le programme se termine, les poignées en débarrasser. L'instruction à l'aide seulement aide, tandis que l'application est en cours d'exécution.
- Les finaliseurs sont l'expression de ce qui fonctionne le nettoyage à la sortie.
InformationsquelleAutor Nick
3

Finalement, l'écrivain sera nettoyé. Lorsque cela se produit est à la hauteur du garbage collector, qui se rendra compte que la dispose de la commande n'a pas été appelé, et à l'appeler. Bien sûr, le GC peut ne pas fonctionner pendant des minutes, des heures ou des jours en fonction de la situation. Si l'écrivain est la tenue d'un verrou exclusif sur le dire, un fichier, aucun autre processus ne sera capable de l'ouvrir, même si vous êtes à la longue fini.

L'aide du bloc assure de Disposer de l'appel est toujours fait, et par conséquent, que la Proximité est toujours appelé, indépendamment de ce que les flux de contrôle se produit.
- Comment est-il nettoyer? Fait-il appel sa propre méthode dispose dans un finaliseur?
- Généralement, pour les membres des références à des ressources non managées, le même code de nettoyage seront appelés à partir à la fois. J'ai dit "Invoquer" ci-dessus, mais il n'y a pas de certitude de Disposer de la fonction appelée. Le comportement sera probablement très similaire dans les deux cas, cependant.
- Le GC jamais appeler un objet de la méthode dispose. Si l'objet a une finaliser alors qui devrait finalement être appelé par le GC, et il est possible que le finaliser pourrait alors manuellement appel Dispose (si c'est le cas ou pas, c'est un détail d'implémentation).
- Oui. La GC s'exécute et détecte tous les objets qui n'ont pas de racines. Avec un finaliseur méthode ne sont pas collectées en file d'attente le finaliseur le thread est démarré. Le finaliseur exécute la méthode dispose sur la le d'attente des objets. (C'est pourquoi vous devriez suivre le bon modèle dispose sur vos propres objets à assurez-vous de faire la bonne chose quand il est appelé à partir d'un outil de finalisation ou d'une aide du bloc). C'est aussi pourquoi il est important que vous utilisez à l'aide, car les objets avec un finaliseur se qualifient pour le prochain GC génération alors que le finalizer est exécuté, de sorte que le survivre beaucoup plus longtemps si ils ne sont pas éliminés correctement.
- Merci pour l'explication. J'ai posté une (sans doute maladroitement formulée) question à propos de cette région hier. Beaucoup de gens semblent se concentrer sur la re-re-expliquer la façon dont l'aide se traduit par try/catch/finally, ce qui n'est pas utile 🙂 @Luc je ne veux pas laisser entendre qu'il sera automatiquement appelé. Juste que le programmeur serait ajouter manuellement les éliminer/nettoyage appel à un outil de finalisation.
- Oups, mon erreur - Le finaliseur thread exécute la méthode finalize, qui devrait à son tour appel de l'jetez méthode si le modèle est correctement mis en place.
- Le finaliser seulement appelle la méthode dispose, si l'auteur de la classe conçu et codé de cette façon (ce qui doit l'avoir fait). C'est un détail d'implémentation, et non garantis par un des specs, etc.
- Mon commentaire visait à Adam, pas vous. Adam réponse suggère que le GC va automatiquement appeler dispose. Il ne sera pas.
- Ouais déjà repéré l'erreur. J'ai été trop de concentration sur le montage en 600 chars =:) je suis d'accord il n'est pas garanti dans tous les caractéristiques, mais la méthode finalizer est là pour faire des ressources de nettoyage, de sorte que même si il ne fait pas appel de la jeter, il sera à tout le moins nettoyer les ressources correctement, sinon, quel a été le point de l'ajouter. Donc, je pense qu'il est juste de dire que le finailzer finira par fermer le flux de données, mais encore de la mauvaise pratique de recourir à compter sur elle.
- Cette réponse n'est pas entièrement exacte. D'autres codes peuvent avoir un handle vers le ruisseau et de la jeter (c'est le cas dans cet exemple, le flux est détenue par ASP.NET qui sera probablement éliminer il, pas d'attente pour le gc)
InformationsquelleAutor Adam Wright
1

À mon avis, il est nécessaire d'envelopper toute classe qui implémente IDisposable dans un bloc using. Le fait qu'une classe implémente IDisposable signifie que la classe a des ressources qui ont besoin d'être nettoyé.
- Que faire si vous avez besoin de maintenir cet état ouvert pour une plus longue période de temps. Comme Async sockets et des ruisseaux. Il y a une raison, vous pouvez implment IDisposible sur votre propre. Aussi IDisposable va fermer le flux de données ainsi. Ce qui signifie que si vous rediriger telles que les streamwriter comme ci-dessus et disposer de la streamwriter le streamwriter va fermer le flux de données qui a été passé au présent. cela peut empêcher l'envoi des données vers le client.
InformationsquelleAutor Jamie Ide
1

Ma règle d'or est, si je vois Disposer énumérés à l'intellisense, je l'envelopper dans un bloc using.
- La bonne règle, mais pas assez. Certaines classes de l'utilisation explicite de la mise en œuvre de IDisposable, masquant Dispose(). Mauvaise idée, mais il est utilisé. Vous avez encore besoin de demander l'aide d'(){}
InformationsquelleAutor n8wrl
0

l'aide de bloquer les appels dispose() quand elle se termine. C'est juste un moyen pratique de s'assurer que les ressources sont nettoyées en temps opportun.
- Idée fausse commune, d'en Disposer est une façon de dire les consommateurs de votre classe que l'objet doit être nettoyé, Finaliseurs sont la façon dont le garbage collector nettoie lorsque l'objet champ d'application de feuilles ou à la fin du programme.
- msdn.microsoft.com/en-us/library/... "Utiliser cette méthode pour fermer ou de libérer des ressources non managées, tels que les fichiers, les ruisseaux, et les poignées tenue par une instance de la classe qui implémente cette interface. Cette méthode est, par convention, utilisé pour toutes les tâches liées à libérer des ressources détenues par un objet, ou de la préparation d'un objet pour la réutilisation."
InformationsquelleAutor Robert
0

Dans presque tous les cas, si une classe implémente IDisposable, et si vous êtes en train de créer une instance de cette classe, alors vous avez besoin de l'aide du bloc.
- existe-il des exceptions?
- Seulement WCF client proxy, pour autant que je sais. Cela est dû à une erreur de conception de la part de Microsoft.
- comment voulez-vous comprendre, c'est une erreur? Il y a des moments, vous devez laisser le sortant de la vapeur de l'ouvrir et ne ferment lorsque le client est terminée. Si vous la fermer avant que le client téléchargé toutes les données de la connexion serait annulée et le client n'aurait jamais recevoir les données
- l'erreur de conception est qu'il se casse quand vous utilisez un bloc using sur un proxy WCF. Si une exception n'est pas gérée dans le bloc, dispose est appelé, qui appelle l'avortement, qui peut jeter son propre exception. Je perds toutes les informations sur le problème d'origine.
- Je considère StreamReader et StreamWriter pour être des exceptions à cette règle. Voir ma réponse.
InformationsquelleAutor John Saunders
0

Alors qu'il est de bonne pratique de toujours jetez jetables classes telles que StreamWriter, comme d'autres, dans ce cas, il n'a pas d'importance.

Réponse.OutputStream seront éliminés par le ASP.NET l'infrastructure lorsque c'est fini, le traitement de votre demande.

StreamWriter suppose qu'il "possède" un Flux de données transmis au constructeur, et donc de Fermer le flux de données quand il est éliminé. Mais dans l'exemple que vous fournissez, le flux a été instancié à l'extérieur de votre code, donc il y aura un autre propriétaire qui est responsable pour le nettoyage.
- Quel est le StreamWriter? Que faire si il a tenu à certaines ressources non managées côté du ruisseau qui l'enveloppe?
- Il ne dispose d'aucune autre ressource non managée. Mais je suis d'accord que c'est une bonne pratique pour la jeter, je signale simplement que, dans cette situation, le flux sera disposé de toute façon.
- Si vous ne jetez pas le StreamWriter, vous devez appeler la méthode Flush() lorsque vous avez terminé. Sinon, une partie de votre sortie peut encore être mis en mémoire tampon, et n'est pas encore écrit dans le flux.
- Blanc: "Si vous ne jetez pas le StreamWriter, vous devez appeler la méthode Flush()" - dans le cas général, oui. Tout ce que je veux dire c'est que dans ce cas précis, l'élimination (et donc de rinçage) est assurée par le ASP.NET l'infrastructure.
InformationsquelleAutor Joe

Vous devez vous connecter pour publier un commentaire.