¿Cuál es su opinión al manejar excepciones dentro de la ejecución de un subproceso? Más específicamente, ¿qué pasa si la excepción se arroja dentro del bloque catch de una cláusula try-catch? ¿Y qué ocurre con el hilo si la excepción no se maneja?Práctica recomendada para manejar excepciones, que se lanzan dentro del bloque catch, en un hilo. (.NET)
¿Cuál es su opinión al manejar excepciones dentro de la ejecución de un hilo?
Debe manejar las excepciones siempre que sea posible y cada vez que espere excepciones. Aclaración: estoy totalmente de acuerdo con John en que no debe manejar excepciones en todas partes, solo donde puede hacer algo al respecto. Sin embargo, nunca debe permitir que una excepción no se controle en un hilo, ya que esto ocasionará problemas graves. Tener un controlador de excepciones raíz y dejar que el hilo muera correctamente (después de registrar el problema, etc.)
Más específicamente, ¿qué pasa si el hilo se lanza dentro del bloque catch de una cláusula try-catch?
¿Querías decir: ¿Qué ocurre si se lanza la excepción dentro del bloque catch? Bueno, entonces no es manejado por el bloque try-catch actual. Lo mejor es no poner demasiado procesamiento en un bloque catch para evitar esta situación tanto como sea posible.
¿Y qué ocurre con el hilo si el hilo no se ha manipulado?
Quizás quiso decir: ¿Qué le sucede al hilo si la excepción no es controlada? Se muere.
Y como Ben mencionado:
Una excepción no capturada en un hilo desencadena una UnhandledException en el dominio de aplicación de hilo. Usted puede ver por estos mediante la adición de un controlador de eventos:
AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
Una excepción no capturada en un hilo desencadena una UnhandledException en dominio de aplicación del hilo. Usted puede ver por éstos mediante la adición de un controlador de eventos:
AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
Tenga en cuenta que no puede "controlar" la excepción en el sentido tradicional. Después de que se haya ejecutado este controlador de eventos, es probable que el AppDomain se muera. Este uso de este evento es principalmente para poder registrar información sobre excepciones o acciones similares. –
Sí, debería haberlo mencionado. –
puedo estar de acuerdo con ren, o al menos con lo que parece que quería decir.
Solo maneja excepciones si realmente puedes manejar ellos. Solo si puede hacer algo sobre lo que salió mal o agregar información. No los manejes solo porque puedes.
try {
// ..
} catch (Exception ex) {
Console.WriteLine(ex.Message);
}
Lo anterior es muy malo. Primero, no muestra la excepción completa, sino solo el Mensaje. Segundo, dejas que las cosas continúen, y no sabes en qué estado está el proceso.
de acuerdo. No quería dar a entender que debería haber bloques try-catch alrededor de cada bit de código. Gracias por atrapar eso. – rein
Estoy totalmente de acuerdo. El tono de la respuesta de rein (aunque aclaró que no quiso dar a entender esto) podría ser para principiantes que escribir bloques de try-catch es algo bueno. Yo diría que intente escribir código de excepción de seguridad, con tan pocos bloques de captura de prueba como sea posible; y solo entonces comienza a preocuparte por las excepciones que realmente puedes manejar en casos muy específicos. Solo en el nivel superior de su aplicación (y posiblemente en los límites principales de las capas de su aplicación), se preocupa por detectar todas las excepciones (para informar y dejar que se agote su aplicación). – jeroenh
Las excepciones no controladas en un hilo provocan la muerte de tu proceso y mueren con un mensaje inútil en el registro de eventos.
Tener controladores de excepción de nivel superior en cada hilo que registra (y tal vez relanzar) es una buena práctica, como lo es instalar un controlador de excepción de dominio de app como las demás respuestas mencionan.
Si cree que puede manejar una excepción, debería atraparla. Todas las demás excepciones que no se puedan tratar deberían aparecer en la superficie de la pila donde, si en el camino no se encuentra un controlador apropiado, el hilo morirá.
No debe escribir ningún código en un bloque catch que pueda arrojar otra excepción, pero si lo necesita puede anidar otro bloque try catch a su alrededor.
Los mecanismos de excepción .net fundamentalmente no proporcionan ninguna buena manera de manejar una excepción que se produce durante la ejecución de un bloque catch, o durante la ejecución de un bloque "finally" mientras hay otra excepción pendiente. El manejo adecuado requeriría que .net soportara un tipo de excepción compuesto que podría ser capturado por bloques de "captura" para cualquiera de sus componentes, pero que se volvería a acumular automáticamente en la pila de llamadas hasta que se hubieran tratado todas las partes constituyentes. Desafortunadamente, .net no proporciona ningún tipo de excepción compuesta; mientras que uno podría definir y usar tipos personalizados de tal manera que se obtenga dicha semántica, el código para usarlos sería bastante feo, y no se integrarían bien con las excepciones que otro código podría arrojar.
En consecuencia, uno se enfrenta a una elección: reprimir la nueva excepción y dejar que la anterior se propague, permita que la nueva se propague y pierda la anterior, o componga un objeto de excepción compuesto que solo puede ser manejado por código que conoce buscarlo Ninguno de ellos es una opción particularmente agradable. Cuál es mejor dependerá de la comprensión de las condiciones que representan los diferentes tipos de excepciones y qué código de llamadas esperarán hacer con ellas.
gracias por atrapar el error tipográfico – weilin8
@rein: no solo el hilo se muere; Destruye todo el proceso. –
Recomiendo de alguna manera incorporar la información en la respuesta de Ben a su última declaración. El hilo se muere si hay una excepción no controlada, pero no se detiene allí. La excepción se propagará por la cadena hasta el Dominio de aplicación y matará tu aplicación si no tienes otro controlador para ella. – jasonh