2009-07-26 6 views
12
WebResponse response; 
try 
{     
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
response = request.GetResponse(); 

request = (HttpWebRequest)WebRequest.Create(url2); 
response = request.GetResponse(); 
} 
catch(Exception ex) 
{ 
//do something 
}    
finally 
{ 
} 

où doit être appelée réponse()?Quand appeler WebResponse.Close()

  • après chaque GetResponse() dans try?

  • après la dernière GetResponse() dans try - once?

  • dans le bloc finally?

Répondre

19

Aucune de ces. Vous devez utiliser un bloc using:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
using (WebResponse response = request.GetResponse()) 
{ 
    using (var stream = response.GetResponseStream()) 
    { 
     using (var reader = new StreamReader(stream)) 
     { 
      var result = reader.ReadToEnd(); 
      // Do something with result 
     } 
    } 
} 

Un bloc using veillera à ce que la méthode Dispose est appelée, si oui ou non il y a une exception. Dispose fera la même chose que Close.

using (var d = new DisposableClass()){code;} 

équivaut à:

DisposableClass d = null; 
try 
{ 
    d = new DisposableClass(); 
    code; 
} 
finally 
{ 
    if (d != null) 
     ((IDisposable)d).Dispose(); 
} 
+1

Pour une explication plus détaillée, vous pouvez montrer comment tous ceux qui utilisent des instructions sont convertis en instructions try/finally :) Seule raison je dis cela parce qu'il a demandé s'il devrait le mettre dans une déclaration finale, que vous faites en quelque sorte ... Évidemment d'une manière plus propre/plus facile à lire. –

+0

Sûrement cela doit être faisable sans utiliser 'using', juste le standard try catch finally blocks? – UpTheCreek

+0

Est-il obligatoire de disposer de l'instance WebResponse? Je ne vois pas disposer dans l'intellisense de Vs2008. –

1

Mettez-le dans le bloc finally. Comme par MSDN:

Le bloc finally est utile pour nettoyage des ressources allouées dans le bloc try ainsi que l'exécution d'un code qui doit exécuter même si est une exception. Le contrôle est toujours passé au bloc finally indépendamment de de la façon dont le bloc try se termine.

+0

Mais s'il met réponse.Fermeture() dans finalement, il obtiendra une erreur «utilisation d'une variable non affectée». – UpTheCreek

-1

Je suggère le ci-dessous

 try 
     { 
      HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://www.google.com"); 
      request.Timeout = 20000; 
      using (var response = request.GetResponse()) 
      { 
       //Do something with response. 
      } 


      request = (HttpWebRequest)WebRequest.Create("http://www.bing.com"); 
      using (var response = request.GetResponse()) 
      { 
       //Do somehing with response 
      } 
     } 
     catch (Exception ex) 
     { 
      //do something 
     } 
     finally 
     { 
     } 
+1

Vous devez certainement disposer/fermer la première instance "request", puisque vous venez d'écraser cette instance avec une nouvelle instance, vous êtes à la merci du Garbage collector lorsque le premier sera éliminé. – Marineio

+2

WebRequest n'implémente pas IDisposable. –

+0

Il n'y a pas de raison pour un bloc 'finally' ici. De plus, sans avoir de code réel dans le 'catch', cette réponse peut laisser la fausse impression que' try/catch' est requis autour de tout le code. –

0

Notez que imbriquée à l'aide de blocs ne nécessitent pas d'accolades, d'améliorer la lisibilité. Ainsi, le code de John Saunder pourrait être écrit:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
using (WebResponse response = request.GetResponse()) 
using (var stream = response.GetResponseStream()) 
using (var reader = new StreamReader(stream)) 
{ 
    var result = reader.ReadToEnd(); 
    // Do something with result 
} 

VS.NET comprend que ces blocs imbriqués ne ont pas besoin indenter. Notez que si vous connaissez le codage de la réponse ou que vous allez l'ignorer, WebClient fournit des informations d'en-tête manquantes, ce qui rend impossible la détection de l'encodage basé sur l'en-tête (transfert/texte).

+0

Je dirais que cela réduit la lisibilité. J'ajoute presque toujours des accolades, même sur des instructions if à une seule ligne, sauf dans de rares cas comme "if (simple-condition) return;" –

+1

Pour les petits fichiers de code peut-être - pour les fichiers réels en ajoutant ces accolades inutiles sur les lignes redondantes signifie que votre code devient beaucoup plus long et moins sur un écran, ce qui signifie que vous aurez moins d'aperçu. L'indice réel devrait de toute façon être l'indentation, et VS.NET indente automatiquement un tel code d'une manière non confuse. –

Questions connexes