forma aceptada para prevenir "El host remoto cerró la conexión" excepción

Question

estoy constantemente conseguir la siguiente excepción que es causada por un usuario iniciar una descarga, y que en consecuencia no (o se cancele):

Error Message : The remote host closed the connection. The error code is 0x80072746. Stack Trace : at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush) at

He buscado en todo el Internet, and found an interesting article, sin embargo, no parece haber una respuesta definitiva como la mejor manera de evitar que esto llene los registros.

El usuario no ve ningún error y no hay ningún problema real en la aplicación, ya que ocurre solo (a mi entender) en situaciones fuera de su control (usuario cancelando descarga o pérdida de conexión) pero tiene que haber una forma de prevenir tal excepción se informa.

Odio decirlo pero estoy tentado de comprobar que esta excepción y la captura vacía bloqueen su trasero, pero esto me hace sentir como un programador sucio.

So - ¿Cuál es el método aceptado para evitar que esta excepción llene mi buzón?

Answer 1

No se puede evitar que un host remoto cierre algo.

Y en algunos protocolos esta es la manera normal (o al menos aceptada) de decir adiós.

Así que tendrá que manejar esta excepción específica.

Answer 2

Desde una perspectiva práctica, no hay nada de malo en cancelar una descarga en virtud de una computadora muerta o una sesión web muerta, por lo tanto, la captura de excepciones de host remoto cerrado es perfectamente aceptable.

Answer 3

El error ocurre cuando intenta enviar una respuesta al cliente pero se han desconectado. Puede verificar esto estableciendo un punto de interrupción en Response.Redirect o donde esté enviando datos al cliente, espere a que Visual Studio llegue al punto de interrupción y luego cancele la solicitud en IE (usando la x en la barra de ubicación). Esto debería provocar el error.

Para capturar el error que se puede utilizar el siguiente:

try 
{ 
    Response.Redirect("~/SomePage.aspx"); 
    Response.End(); 
} 
catch (System.Threading.ThreadAbortException) 
{ 
    // Do nothing. This will happen normally after the redirect. 
} 
catch (System.Web.HttpException ex) 
{ 
    if (ex.ErrorCode == unchecked((int)0x80070057)) //Error Code = -2147024809 
    { 
     // Do nothing. This will happen if browser closes connection. 
    } 
    else 
    { 
     throw ex; 
    } 
} 

O en C# 6, se pueden utilizar filtros de excepción para evitar tener que volver a tirar el error:

try 
{ 
    Response.Redirect("~/SomePage.aspx"); 
    Response.End(); 
} 
catch (System.Threading.ThreadAbortException) 
{ 
    // Do nothing. This will happen normally after the redirect. 
} 
catch (System.Web.HttpException ex) when (ex.ErrorCode == unchecked((int)0x80070057)) 
{ 
    // Do nothing. This will happen if browser closes connection. 
} 

que es una mejor la experiencia de depuración ya que se detendrá en la declaración arrojando la excepción con el estado actual y todas las variables locales conservadas en lugar de en el tiro dentro del bloque catch.