¿Por qué CLR vuelve a lanzar ThreadAbortException?

que tiene el siguiente código del libro "Programación Concurrente en Windows":¿Por qué CLR vuelve a lanzar ThreadAbortException?

void Main() 
{ 
    try 
    { 
     try 
     { 
      Console.WriteLine("Inside Main Method"); 
      Thread.CurrentThread.Abort(); 
     } 
     catch(ThreadAbortException) 
     { 
      Console.WriteLine("Inside First Catch"); 
      // Trying to swallow but CLR throws it again.... 
     } 
    } 
    catch(ThreadAbortException) 
    { 
     Console.WriteLine("Inside Second Catch"); 
     //Thread.ResetAbort(); 
    } 
}

Estoy interesado en saber qué tan CLR re-lanza el ThreadAbortException? Y lo sigue haciendo hasta que llamo "Thread.ResetAbort()". En segundo lugar, ¿hay alguna otra excepción definida por el sistema, que reciba un tratamiento especial de CLR?

Fuente

2011-11-23 Pawan Mishra

También tenga en cuenta que el código que llama a Thread.ResetAbort() necesita un permiso especial para poder hacerlo. Por lo tanto, si aloja CLR o crea un AppDomain, puede usar esta característica para hacer que los hilos abortivos sean más deterministas. – Konstantin

Estoy interesado en saber qué tan CLR re-lanza el ThreadAbortException?

Porque el hilo está siendo abortado. Las personas manejan todas las excepciones todo el tiempo, aunque hacerlo es peligroso. Sería extraño si una rutina de registro de errores, por ejemplo, mantiene un hilo que se supone que se destruirá vivo para siempre, ¿no?

¿Hay alguna otra excepción definida por el sistema, que recibe un tratamiento especial de CLR?

Sí, hay varios. Las excepciones fuera de pila y sin memoria, por ejemplo, también tienen comportamientos especiales.

Fuente

2011-11-23 06:41:42

Gracias por la respuesta. Solo quería preguntar, ahora que conozco este comportamiento, ¿es recomendable encapsular el código basado en subprocesos dentro del bloque try-catch "ThreadAbortException"? Como la excepción se va a volver a lanzar de todos modos, el comportamiento puede sorprender a alguien que no conoce la forma en que se comporta esta excepción. –

@PawanMishra: Dos buenas reglas vienen a la mente. El primero es "nunca abortar un hilo". Terminar un hilo normalmente; si no puedes, mata todo el proceso. Abortar un hilo es * increíblemente peligroso *. Segundo, "nunca manejes una excepción de la que no puedas hacer nada". Nunca hay nada bueno que hacer cuando un hilo está siendo abortado. Como nunca vas a abortar un hilo, y nunca vas a manejar la excepción si lo haces, escribir el bloque catch es un poco inútil, ¿no? –

Volviendo a preguntar a la segunda pregunta de OP: _¿Hay alguna "excepción definida por el sistema [que] reciba un trato especial del CLR"? Hay procesos de subprocesos/procesos que hacen que sucedan cosas, pero no veo que las excepciones sean en sí mismas especiales, como se puede ver [aquí] (http://share.linqpad.net/hs2pkf.linq). Obviamente, tuve que saltar un aro o dos para permitir que mi código (re) arrojara una 'ThreadAbortException', y puede haber otras excepciones que sí hacen cosas divertidas cuando se lanzan, pero parece que no. (El verdadero desbordamiento de la pila y los hilos abortados _states_ obviamente tienen un tratamiento especial.) –

Es una excepción especial, http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx, ver observaciones. Según tengo entendido, la razón por la que esto sucede es que .Net le brinda la posibilidad de realizar cualquier tarea de limpieza antes de que el hilo se cierre.

ver esto por un poco acerca de la instalación de cañerías: http://ondotnet.com/pub/a/dotnet/2003/02/18/threadabort.html

Fuente

2011-11-23 06:09:18 Prescott

¿Por qué CLR vuelve a lanzar ThreadAbortException?

Respuesta

Cuestiones relacionadas