2009-07-26 17 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 
{ 
} 

donde debe llamarse response.Close()?Cuándo llamar a WebResponse.Close()

  • después de cada GetResponse() in try?

  • después del último GetResponse() in try - once?

  • en el bloque finalmente?

Respuesta

19

Ninguna de las anteriores. Usted debe utilizar un bloque 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 bloque using se asegurará de que el método Dispose se llama, si existe o no es una excepción. Dispose hará lo mismo que Close.

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

es equivalente a:

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

Para una explicación más detallada, podría mostrar cómo todas las declaraciones que utilizan se convierten en declaraciones try/finally :) La única razón por la que digo esto es porque él preguntó si debería ponerlo en una declaración finally, que en cierto sentido está haciendo ... Obviamente de una manera más limpia/más fácil de leer. –

+0

Seguramente esto debe ser factible sin usar 'usar', solo los bloques de captura de prueba estándar finalmente? – UpTheCreek

+0

¿Es obligatorio disponer de la instancia de WebResponse? No veo disponer en el intellisense de Vs2008. –

1

Colóquelo en el bloque finally. Según MSDN:

El bloque finally es útil para la limpieza de los recursos asignados en el bloque try , así como ejecutar cualquier código que debe ejecutar incluso si no es una excepción. El control siempre es pasado al bloque finally independientemente de de cómo sale el bloque try.

+0

Pero si pone response.Close() finalmente obtendrá un error de 'uso de variable sin signo'. – UpTheCreek

-1

que sugeriría el siguiente

 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

Seguramente tiene que deshacerse/cerrar la primera instancia de "solicitud", ya que simplemente sobrescribe esa instancia con una nueva, está a merced del recolector de basura para cuando esa primera se elimine. – Marineio

+2

WebRequest no implementa IDisposable. –

+0

No hay ninguna razón para un bloque 'finally' aquí. Además, sin tener un código real en 'catch', esta respuesta puede dejar la falsa impresión de que se requiere 'try/catch' alrededor de todo el código. –

0

Tenga en cuenta que el uso de bloques anidados no necesitan llaves, mejorar la legibilidad. Así código de John Saunders se podría escribir:

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 entiende que tales bloques anidados no necesitan sangría. Tenga en cuenta que si conoce la codificación de la respuesta o la va a ignorar, WebClient proporciona una API más simple: falta información de encabezado, por lo que la detección de codificación basada en encabezado (transferencia/texto) se vuelve imposible, pero de lo contrario funciona bien.

+0

Yo diría que esto reduce la legibilidad. Casi siempre agrego llaves, incluso en sentencias if de una sola línea, excepto en casos raros como "if (simple-condition) return;" –

+1

Para bits cortos de código, tal vez, para los archivos reales agregar estas llaves innecesarias en líneas redundantes significa que su código es mucho más largo y menos ajustes en una pantalla, lo que significa que tendrá menos visión general. La pista real de todos modos debe ser una sangría, y VS.NET sangra automáticamente dicho código de una manera no confusa. –

Cuestiones relacionadas