¿Captar todas las excepciones, buenas o malas?

Question

que he visto en varios proyectos de una especie de cajón de sastre excepción a coger toda excepción inesperada por lo que la aplicación no se bloqueará, veo esto por lo general con:

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(myUnexpectedExhandler); 
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(threadExHandler); 

¿Es esta una práctica buena o mala.

Answer 1

La captura de excepciones en el nivel superior de su proyecto está bien y es correcta. Allí, puedes hacer cosas como registrarlo, informar los detalles a tu equipo, etc. Las excepciones deberían publicarse definitivamente en algún lugar, si es posible, eso ayuda mucho en términos de desarrollar un producto sólido como una roca (ver Jeff Atwood's entrada de blog "Exception-Driven Development" para un comentario sobre esto).

Lo que es una mala práctica es atrapar excepciones de forma inapropiada en la pila de llamadas. La única vez que debe atrapar una excepción es cuando sabe exactamente qué hacer con ella. Ciertamente, nunca, nunca, jamás, jamás, tragarán silenciosamente las excepciones.

Answer 2

En general, yo diría que depende totalmente de usted, pero para mí depende de la fase en la que se encuentre actualmente un proyecto. Durante el desarrollo inicial de cualquier proyecto, prefiero excepciones no detectadas para mostrar un bonito mensaje de error descriptivo con qué línea de código bombardeó para poder arreglarlo.

vez que un sitio madura, sin embargo, utilizar una clase personalizada ManejadorError que he construido y tienen todas las errores registrados en una tabla de base de datos, y también tienen una hora (o diario) Lista de errores correo electrónico a la promotora a cargo del proyecto. Los errores especiales que requieren un manejo delicado suelen tener un try/catch alrededor de las líneas específicas de código que podrían romperse.

Answer 3

Cada proyecto en el que trabajo finalmente obtiene un controlador de excepción global como ese.

Answer 4

Yo personalmente no creo que sea una buena práctica solo confíe en eso en producción. Cualquier método o acción que pueda causar una excepción debe ser manejado en esa etapa (try..catch o pasado a una clase de controlador de cliente, etc.). No solo hace que la aplicación sea más robusta, ya que puede manejar excepciones específicas de una manera que sea adecuada para la situación, pero también hace que sea más fácil averiguar por qué se lanza la excepción. También hay muchos marcos de registro disponibles que hacen que sea más fácil registrar excepciones y manejar los errores.

Usaría las excepciones 'atrapar todo', pero solo como la última línea de manejo de errores.

Answer 5

Diría que es una pregunta muy discutible entre muchos programadores que tienen experiencias diferentes y tienden a tener opiniones diferentes. Mi respuesta puede ser un poco larga, pero siento que no puedo responderla en pocas palabras.

que creen en lo que sigue en base a mi experiencia:

1. Conocer el requisito de negocio. Si es una aplicación crítica, sí, es muy cierto que no debemos permitir que la aplicación continúe y simplemente permitir que se bloquee mostrando al usuario algún mensaje apropiado.
2. Si no es una aplicación muy importante, y desea que el usuario continúe utilizando la aplicación haciendo alguna otra tarea, tiene sentido permitir que la aplicación se recupere correctamente.

Para agregar a los 2 puntos anteriores, también me gustaría decir que no puede recuperar ninguna aplicación si se produce una aplicación no controlada en cualquier hilo que haya creado. Solo se pueden recuperar excepciones en el hilo principal de la GUI.

El objetivo de agregar dicho código es asegurarse de que la depuración y la generación de informes de errores sean más simples y fáciles. Por ejemplo, supongamos que tiene una aplicación muy grande y se produce una excepción inesperada en algún lugar de su código. Ahora bien, si tiene controladores como los mencionados, puede centralizar todo y registrar el seguimiento de la pila, los mensajes, etc. Y una vez que tenga todo el registro, es cuestión de tiempo para resolver el problema y conocer su origen.

Espero que ayude !!

Answer 6

utilizo regularmente este tipo de manipuladores de excepciones en la producción, y mi práctica es que yo los puedo utilizar para:

• informar a los usuarios de que algo malo sucedió, pero que me importa y resolveré como tan pronto como sea posible - es mejor hacer eso en lugar de mostrar el diálogo de bloqueo de ventanas aburridas estándar
• enviarme un correo electrónico con mensaje de excepción, seguimiento de pila y cualquier otra información interesante
• capturar y recuperar de excepciones conocidas que son inevitables en el código e intentan avanzar de una manera menos catastrófica

HTH

Answer 7

Por mi opinión es una muy buena práctica para capturar y excepciones en la aplicación a nivel de registro.

PERO Eso definitivamente no significa que ya no tenga que manejar excepciones, tiene que manejar las excepciones de clases individuales que usted espera.

Las excepciones de la aplicación se deben usar solo para que el programa no se bloquee y no se utilice como un gran intento de capturar la aplicación.

De nuevo esa fue su opinión personal.

Answer 8

Creo que un controlador global de excepciones sería una buena cosa. Si su programa falla, entonces le permite un espacio único para tratar de escupir un bit más de datos para que pueda descubrir por qué se estrelló. No se sugerirá la recuperación de un manejador global de excepciones porque probablemente no sea el caso de que sepa cómo recuperarse de una excepción arbitraria en el nivel superior.

Answer 9

Si va a registrar la excepción no detectada, siempre logre un stacktrace con ella. odio obtener informes de errores que tienen un registro como: "Excepción no controlada" o "excepción no controlada: IndexOutOfRangeException"

Gracias, compañeros de trabajo. Eso es genial.