.net - sentencia - Capturas todas las excepciones buenas o malas?

relanzar una excepcion (9)

He visto en varios proyectos una especie de excepción de capturar todos para detectar todas las excepciones inesperadas, por lo que la aplicación no se bloquea, lo veo generalmente con:

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

¿Es esta una buena o mala práctica?

Cada proyecto en el que trabajo finalmente obtiene un controlador global de excepciones como ese.

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.

Creo en lo siguiente basado en mi experiencia:

Conozca el requisito comercial. Si es una aplicación crítica , sí, es muy cierto, no debemos permitir que la aplicación continúe y simplemente permitir que se bloquee mostrándole al usuario algún mensaje apropiado.
Si no es una aplicación muy crítica , y desea que el usuario continúe usando la aplicación realizando alguna otra tarea, tiene sentido permitir que la aplicación se recupere correctamente.

Para agregar a los 2 puntos anteriores, también quisiera 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 el informe de errores se vuelvan 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!!

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

Sin embargo, una vez que un sitio madura, utilizo una clase ErrorHandler personalizada que he creado y que registra todos los errores en una tabla de base de datos, y también tengo una lista de errores por hora (o diaria) enviada por correo electrónico al desarrollador 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.

En mi opinión, es una muy buena práctica capturar y registrar excepciones en el nivel de la aplicación.

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

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

Nuevamente esa fue una opinión personal.

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 publicación de blog " Desarrollo impulsado por excepciones " 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.

Personalmente, no creo que sea una buena práctica confiar exclusivamente 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 de ''atrapar todo'', pero solo como la última línea de manejo de errores.

Regularmente utilizo manejadores de excepciones en producción, y mi práctica es que puedo usarlos para:

informar al usuario que algo malo sucedió, pero que me importa y lo resolveré lo antes posible; es mejor hacerlo en lugar de mostrar el diálogo de bloqueo de ventanas aburrido estándar
me envía un correo electrónico con mensaje de excepción, seguimiento de pila y cualquier otra información interesante
atrapar y recuperarse de las excepciones conocidas que son inevitables en el código e intentar avanzar de una manera menos catastrófica

HTH

Si vas a registrar la excepción no detectada, siempre registra una 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.

Yo pensaría que un manejador de excepción global sería algo bueno. 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 recomendaría la recuperación desde un manejador global de excepciones porque probablemente no sea el caso que sepa cómo recuperarse de una excepción arbitraria en el nivel superior.