2009-06-30 6 views
9

que tiene algún error extraño con response.redirect() y el proyecto no fue la construcción en todos los .. cuando quité el bloque try-catch que rodeaba el bloque de código en la que se encontraba en Response.Redirect() funcionó normalmente ..¿Hay algo que impida que Response.Redirect funcione dentro del bloque try-catch?

Solo quiero saber si esto es un problema conocido o algo ...

+2

¿Se puede publicar el código que no se compilaría? –

+0

@Fredrik: Acepto que la mayoría de las respuestas aquí solo pueden adivinar lo que está sucediendo. La acción continuada de una threadabortexception puede estar relacionada, pero es difícil de decir sin el verdadero error que ocurrió y el mismo código de ejemplo. – AnthonyWJones

+1

Su código ni siquiera compila, ¿por qué estamos hablando de tirar y atrapar ThreadAbortException? –

Respuesta

23

Si no recuerdo mal, Response.Redirect() arroja una excepción para abortar la solicitud actual (ThreadAbortedException o algo así). Entonces podrías estar atrapando esa excepción.

Editar:

Este KB article describe este comportamiento (también para los métodos de 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 se utiliza la otra sobrecarga), se emite la excepción y la solicitud actual finalizará inmediatamente.

+0

+1. Tenga en cuenta que el uso de 'Redirigir' sin lanzar continuará la ejecución de la solicitud (o al menos funciones en la pila actual) que pueden ocasionar efectos secundarios interesantes (es decir, información persistente o registro que no se ejecutaría si se lanza una excepción).Se debe tener cuidado de no ejecutar ningún código no trivial después de la redirección intencional. –

+0

esto funcionó muy bien para mí ¡Excelente respuesta! – Kaos

4

Como Martin señala, Response.Redirect arroja una ThreadAbortException. La solución es volver a emitir la excepción:

try 
{ 
    Response.Redirect(...); 
} 
catch(ThreadAbortException) 
{ 
    throw; // EDIT: apparently this is not required :-) 
} 
catch(Exception e) 
{ 
    // Catch other exceptions 
} 
+1

No necesita volver a lanzar ThreadAbortException. El tiempo de ejecución automáticamente lo resucitará de todos modos al final del bloque catch. Consulte la sección de comentarios de http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx – LukeH

+0

No es necesario volver a lanzar esta excepción, después de que cada bloque try catch haya manejado esta excepción, la excepción es vuelto a lanzar por el CLR de todos modos. Solo puede detener esto llamando a Thread.ResetAbort() pero yo no lo recomendaría. – AnthonyWJones

+0

Ok :-) Pero aún necesita capturar ThreadAbortException por separado (o verificar el tipo de la excepción manualmente) –

3

Martin es correcta, un ThreadAbortException se tira cuando se utiliza un Response.Redirect, ver la kb article here

-3

No creo que haya ningún problema conocido aquí.

Simplemente no puede hacer una redirección() dentro de un bloque try/catch porque Redirect deja el control actual a otro .aspx (por ejemplo), lo que deja la captura en el aire (no puede volver a ella)

EDITAR: Por otro lado, podría haber tenido todo esto calculado hacia atrás. Lo siento.

+1

Eso no es correcto. Cuando se llama a Response.Redirect(), se lanza una ThreadAbortException, que se puede capturar. –

+0

Sí, se olvidó de pensar mientras escribía :), mis disculpas. – tzup

0

Puede haber hecho referencia a una variable que se declara dentro del bloque try.

Por ejemplo, el siguiente código es válido:

try 
{ 
    var b = bool.Parse("Yeah!"); 
} 
catch (Exception ex) 
{ 
    if (b) 
    { 
    Response.Redirect("somewhere else"); 
    } 
} 

Debe salir a la declaración b fuera del bloque try-catch.

var b = false; 
try 
{ 
    b = bool.Parse("Yeah!"); 
} 
catch (Exception ex) 
{ 
    if (b) 
    { 
    Response.Redirect("somewhere else"); 
    } 
} 
Cuestiones relacionadas