¿Cómo puedo detectar una ThreadAbortException en un bloque finally? (.NET)

Question

Tengo una lógica crítica en un bloque finally (con un bloque try vacío), porque quiero garantizar que el código se ejecute incluso si el hilo se cancela. Sin embargo, también me gustaría detectar ThreadAbortException. Descubrí que al envolver mi bloque try/finally crítico en try/catch no se detecta ThreadAbortException. ¿Hay alguna forma de detectarlo?

 
try { 
    try { } 
    finally { 
     // critical logic 
    } 
} catch(Exception ex) { 
    // ThreadAbortException is not caught here, but exceptions thrown 
    // from within the critical logic are 
} 

Answer 1

Este es un problema curioso.

El código que ha publicado debe funcionar. Parece que hay algún tipo de optimización que decide no llamar a su controlador de captura.

lo tanto, quería para detectar la excepción con esto:

bool threadAborted = true; 
try { 
    try { } 
    finally { /* critical code */ } 
    threadAborted = false; 
} 
finally { 
    Console.WriteLine("Thread aborted? {0}", threadAborted); 
} 
Console.WriteLine("Done"); 

(. Mi código actual simplemente dormía en esa sección de código crítico, por lo que podía estar seguro de que iba a abortar después de que por fin)

Imprimió:

¿Ha abortado el hilo? Falso

¡Hmmm, extraño de hecho!

así que pensé en hacer un poco más trabajo allí, para engañar a las optimizaciones "inteligentes":

bool threadAborted = true; 
try { 
    try { } 
    finally { /* critical code */ } 
    threadAborted = AmIEvil(); 
} 
finally { 
    Console.WriteLine("Thread aborted? {0}", threadAborted); 
} 
Console.WriteLine("Done"); 

Dónde AmIEvil es simplemente:

[MethodImpl(MethodImplOptions.NoInlining)] 
static bool AmIEvil() { 
    return false; 
} 

Finalmente se imprimen:

¿Hilo abortado? Verdadero

Y ahí lo tienes. Utilizar esto en su código:

try { 
    try { } 
    finally { /* critical code */ } 
    NoOp(); 
} 
catch (Exception ex) { 
    // ThreadAbortException is caught here now! 
} 

Dónde NoOp es simplemente:

[MethodImpl(MethodImplOptions.NoInlining)] 
static void NoOp() { } 

Answer 2

Lee sobre Constrained Execution Regions.

Específicamente, el RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup method será útil aquí.

Answer 3

En realidad, se puede ejecutar el código en la declaración de catch muy bien para una ThreadAbortException. El problema es que la excepción se volverá a ejecutar una vez que la ejecución abandone el bloque catch.

Si realmente desea evitar que la excepción continúe, puede llamar a Thread.ResetAbort(). Sin embargo, esto requiere confianza total y, a menos que tenga un escenario específico, es casi seguro que no es lo correcto.

ThreadAbortException

Answer 4

no creo que es posible.

¿Por qué necesita manejar el ThreadAbortException en primer lugar? Llamar a thread.Abort() suele ser un signo de mal diseño. Tener una variable de indicador que cuando se establece en verdadero simplemente devuelve ; de la función de hilo, después de la limpieza adecuada, por supuesto.

De esta manera no tendrá que preocuparse por la excepción.

Answer 5

Estoy de acuerdo con arul. Calling Thread.Abort() es un signo de mal diseño.

Permítanme citar Peter Ritchie de MSDN: Thread.Abort (el subrayado es mío):

Hay muchas razones para no utilizar Thread.Abort y ThreadAbortException

En ciertas plataformas (como x64 y IA64) del El aborto puede ocurrir antes de que Monitor.Enter y un bloque try (incluso con lock/SyncLock), dejando el monitor huérfano. ThreadAbortException puede ocurrir en un código de terceros no escrito para manejar el aborto de subprocesos. El hilo se puede cancelar mientras se procesa un bloque finally en .NET 1.x Utiliza excepciones para la lógica de flujo de control normal. La excepción asincrónica puede interrumpir la modificación del estado o los recursos del fragmento, dejándolos dañados.

Para más detalles, véase:
http://msmvps.com/blogs/peterritchie/archive/2007/08/22/thead-abort-is-a-sign-of-a-poorly-designed-program.aspx
http://www.bluebytesoftware.com/blog/2007/01/30/MonitorEnterThreadAbortsAndOrphanedLocks.aspx
http://blogs.msdn.com/ericlippert/archive/2007/08/17/subtleties-of-c-il-codegen.aspx

Answer 6

¿Has probado algo como esto?

try { 
    try { } 
    catch (ThreadAbortException) 
    { 
     ThreadAbortExceptionBool = true; 
    } 
    finally { 
     // critical logic 
     if (ThreadAbortExceptionBool) 
      // Whatever 
    } 
} 
catch(Exception ex) { 
    // ThreadAbortException is not caught here, but exceptions thrown 
    // from within the critical logic are 
} 

Answer 7

Si llama Thread.Abort es un mal diseño ¿por qué llamar a SQL Server en un hilo que ejecuta código de usuario? Porque así es exactamente como se maneja una cancelación de consulta y causa pesadillas.