2009-09-01 25 views
5

Estoy aprendiendo ASP.NET y estaba buscando QueryStrings.¿Por qué recibo una excepción lanzada cuando ejecuto Response.Redirect()?

Uno de los ejemplos que estaba mirando engancha un botón hasta una llamada de redirección:

protected void btnSubmit_Click(object sender, EventArgs e) 
    { 
     try 
     { 
      //throws ThreadAbortException: "Thread was being aborted" 
      Response.Redirect("Form2.aspx"); 
     } 
     catch (Exception Ex) 
     { 
      System.Diagnostics.Debug.WriteLine(Ex.Message); 
     } 
    } 

¿Por qué lanzar una ThreadAbortException aquí? ¿Eso es normal? ¿Debo hacer algo al respecto? Las excepciones generalmente no son buenas, así que me alarmé cuando vi esto.

+0

http://stackoverflow.com/questions/1063625/is-there -algo que-previene-respuesta-redirecciona-al-trabajo-dentro-try-catch-block –

Respuesta

12

Esto es por diseño. Este KB article describe el comportamiento (también para los métodos Request.End() y Server.Transfer()).

Para Response.Redirect() existe una sobrecarga:

Response.Redirect(String url, bool endResponse) 

Si pasa endResponse = false, entonces la excepción no se lanza (pero el tiempo de ejecución continuará la tramitación de la solicitud actual).

Si endResponse = true (o si usa la sobrecarga sin el argumento bool), se lanza la excepción y la solicitud actual finalizará inmediatamente.

+2

Dudo que en realidad sea 'por diseño', tal vez una desafortunada consecuencia de su diseño? ;) – MedicineMan

+2

"Por diseño" no implica que el diseño elegido sea perfecto ;-) – M4N

3

Esto es normal. Server.Transfer() también arroja la misma excepción.

Esto se debe a que, internamente, ambos métodos llaman al Response.End(), lo que anula el procesamiento de solicitud actual inmediatamente. Rick Strahl tiene un pretty good blog post que analiza por qué no hay prácticamente nada que pueda hacer para evitar estas excepciones.

1

Creo que debe seguir las instrucciones de este artículo de KB. Response.Redirect llama a Response.End(), a menos que haya utilizado la sobrecarga creada específicamente para evitar este comportamiento. Una vez que se ha terminado la respuesta, no pueden ocurrir más operaciones, por lo tanto, la TA exc.

http://support.microsoft.com/kb/312629

2

Es normal en que es lo que está destinado a suceder. Básicamente, cuando la respuesta se ha establecido en una redirección, ASP.NET espera que haya terminado por completo con la solicitud. Interrumpe el hilo como una forma de evitar que se produzca cualquier otro procesamiento (básicamente llama al Response.End y arroja la excepción).

Me parece que es un poco un abuso de excepciones, pero así es como funciona. Puede usar la sobrecarga que tiene un segundo parámetro (y pasar false) para evitar que esto suceda, pero si es así, asegúrese de que nada más intente escribir en la respuesta.

0

Llamar a la sobrecarga de redirección() que sólo se necesita una URL también se traduce en una llamada a Response.End() - que emite una excepción ThreadAbort a garantizar que ningún otro código después de la redirección en su página/UC se ejecuta.

No debería detectar esta excepción ..debe ignorarlo en su código o usar la sobrecarga de Redirect() que toma un booleano que indica si continuará procesando la solicitud después de la redirección.

2

Response.Redirect llama Response.End internamente, por lo que produce la excepción, utilice en su lugar:

Response.Redirect(url, false); 
0

Sí. Codigo un sub de salida después de esos, pero sé que no se alcanzó.

Supongo que si quisieras, podrías comer la excepción y llevar más cosas después, pero yo no lo recomendaría.

0

Ya hay un montón de respuestas razonables aquí. Otro punto que vale la pena señalar sin embargo. La excepción Thread Abort es una de esas raras excepciones que puede detectar y codificar en contra, pero no puede suprimir. Se vuelve a subir automáticamente al final de cualquier bloque try/catch/finally independientemente de lo que hagas.

Y si decide vivir con esta excepción, debe asegurarse de que su monitorización de la salud lo permita y no lo informe como un problema, por lo que no se quedará atrapado frente a un grupo de dispositivos no técnicos. gerentes que intentan explicar por qué su sitio web está lanzando tantas excepciones de aborto de subprocesos. (Tuve un gerente convencido de que todos estos abortos de subprocesos estaban dejando un desorden detrás del cual, por supuesto, era todo lo contrario a la intención del aborto del hilo).

Cuestiones relacionadas