Cuando se le pide que corrija errores en un programa, encontrará más de 100 instancias de

Corrija los errores que se le propuso hacer e informe de la excepción de tragar bloques como nuevos errores críticos.

El primer objetivo intermedio es obtener una buena imagen de qué excepciones se están ignorando y dónde; para ese propósito, simplemente puede agregar código de registro a cada uno de esos bloques horribles catch-everything, mostrando exactamente qué bloque es, y qué captura y oculta. Ejecute el conjunto de pruebas sobre el código así instrumentado, y tendrá un "blueprint" inicial para el trabajo de reparación.

Si no tienes un conjunto de pruebas, entonces, primero, haz una tests las pruebas unitarias pueden esperar (echa un vistazo Feathers' great book on working with legacy code definitely legacy code is most definitely your problem here;-), pero necesita un conjunto de pruebas de integración que se puedan ejecutar automáticamente y hacer cosquillas a todos los errores que se supone que debe corregir.

A medida que avanza y corrige un error tras otro (muchos no serán causados por los bloques de captura excesivamente amplios, solo ocultos / "pospuestos" por ellos; -), asegúrese de trabajar de una manera principalmente "basada en pruebas": agregue una prueba unitaria que marque el error, confírmelo se rompe, arregla el error, vuelve a ejecutar la prueba unitaria para confirmar que el error se ha ido. Su conjunto de pruebas unitarias en crecimiento (con todo lo posible burlado o falsificado) se ejecutará rápidamente y puede seguir volviendo a ejecutar a bajo costo mientras trabaja, para detectar posibles regresiones lo antes posible, cuando todavía son fáciles de arreglar.

El tipo de tarea que se le ha asignado es en realidad más difícil (y a menudo más importante) que las tareas de desarrollo de software de" alto prestigio", como prototipos y nuevas arquitecturas, pero a menudo malinterpretadas y ¡poco apreciado (y por lo tanto poco recompensado!) por la gerencia/clientes; asegúrese de mantener un canal de comunicación muy claro y abierto con el stakeholder, señalando toda la enorme cantidad de trabajo exitoso que está haciendo, lo desafiante que es y (por su bien más que el suyo propio), cuánto habrían ahorrado haciéndolo bien en primer lugar (tal vez la próxima vez lo harán... Lo sé, soy un optimista de ojos salvajes por naturaleza;-). Tal vez incluso te asignen un socio en la tarea, y tú luego puede hacer revisiones de código y emparejar la programación, aumentando enormemente la productividad.

Y, por último, pero no menos importante, ¡buena suerte!!! unfortunately desafortunadamente, lo necesitarás... afortunadamente, como dijo Jefferson, "cuanto más duro trabajo, más suerte parezco tener"; -)

Cambie los bloques de captura de la siguiente manera:

catch (Exception ex)
{
    Logger.Log(String.Format(
        System.Globalization.CultureInfo.InvariantCulture,
        "An exception is being eaten and not handled. "+
        "This may be hiding critical errors.\n"+
        "Exception: {0}",
        ex));
}

Wow....

Dudaría en arrancarlos porque las probabilidades son que solo crearían más "errores". Un primer paso sería agregar registros para que sepa lo que está pasando. Después de tener suficiente información que sería capaz de proceder refactorización....cuidadosamente

Las pruebas unitarias serían una excelente manera de probar cualquier refactorización que realice. También me gustaría sugerir conseguir un montón de ellos en su lugar.

La solución que debe elegir depende en gran medida del entorno en el que esté trabajando.

Las pautas de codificación que he escrito y presentado a la mayoría de mis clientes, establecen explícitamente que las cláusulas de captura vacías sin comentarios (exactamente como se muestra en su pregunta) pueden eliminarse sin ninguna discusión. La razón por la que escribí esta regla es porque encuentro este tipo de declaraciones todo el tiempo y casi siempre ocultan muchos errores. Por lo general, cuanto más código hay en el bloque try, esconden más bichos. A lo largo de los años he descubierto (y resuelto) muchos errores simplemente eliminando las cláusulas de captura vacías. El procedimiento suele ser el mismo:

1. Quito una captura.
2. El código va a producción.
3. Después de algún tiempo, los clientes se quejan de que el programa dejó de funcionar (obtuvo una excepción).
4. Empiezo a investigar el problema y descubro que esta parte del sistema nunca funcionó realmente, y varios desarrolladores han intentado encontrar errores relacionados con esto causa, pero nunca encontró el problema. O peor, encontraron el problema y escribieron esa declaración de captura para' resolver ' el problema.
5. Soluciono el problema real que fue barrido debajo de la alfombra y cierro múltiples informes de errores a la vez.

Si bien este método me ha servido (y a mis clientes) bien estos años, hay un 'pero'. Por ejemplo, uno de mis clientes actuales es una institución médica y los desarrolladores estaban interesados en usar mis pautas de codificación. Sin embargo, insistí en que elimine esa regla particular de las pautas. Si bien su software tiene una gran cantidad de esas declaraciones de captura vacías (más de 100) y esas cosas molestas ocultan muchos errores y me byte todo el tiempo mientras trabajo con su software; debe tener mucho cuidado en este tipo de aplicaciones. En este escenario, comenzaría agregando declaraciones de registro, en lugar de eliminarlas. Después de esto, puede eliminarlos lentamente uno por uno cuando sepa qué tipos de excepciones ocurren y por qué el anterior el desarrollador agregó esa declaración de captura en primer lugar.

En todos los casos, debe tener una declaración de captura general en la parte superior de su aplicación (o tener un controlador de excepciones en su aplicación web) que registrará cualquier excepción que aparezca.

Nota adicional, mis directrices también señalan que configuraría Visual Studio para interrumpir todas las excepciones, yendo a Debug / Exceptions... / Common Language Runtime Exceptions y marque la casilla de verificación' Lanzado'. De esta manera detectas una excepción inmediato.

Advertencia: Este es un consejo general y peculiaridades en su entorno pueden hacerlo imposible, por ejemplo, presiones de tiempo.

Ripea todos ellos con la excepción de en los puntos de entrada al sistema (métodos principales, puntos finales de servicio, pilas de llamadas superiores de subprocesos, controladores de eventos - para código de interfaz de usuario) y agrega el registro/manejo de errores a los lugares donde permanecen los controladores de excepciones.

El inicio de un proceso de agregar los controladores de nuevo en donde sea necesario, es decir, lugares donde las excepciones deben ser manejadas más abajo, con el registro apropiado/informe de errores.

Hacer que el sistema vuelva a funcionar depende de tener un buen conjunto de pruebas de aceptación/regresión para verificar que el sistema es correcto después de que se realicen todos los cambios.

Obviamente, el registro de todas las excepciones suprimidas es el primer lugar para comenzar: la supresión general es útil de vez en cuando cuando necesita asegurarse de que su código se degrada correctamente bajo todas las circunstancias (es decir, cuando no desea ser atrapado por un tipo de excepción que no pudo anticipar), pero puede ocultar un problema imprevisto que necesita más manejo que simplemente ser ignorado, por lo que es imperativo que todos los controladores de excepciones la excepción ha sido suprimida, por lo que tienes un rastro claro de pistas a seguir si surge un comportamiento inesperado.

Eliminar las capturas es una tontería, ya que habrá muchos casos en los que algunas excepciones deben ser "manejadas" para que el programa funcione correctamente (aunque puede estar en desacuerdo con cómo se manejan, y puede haber riesgos asociados con este enfoque, el autor original tenía una razón para escribir el código de esta manera. Ig no ha añadido un comentario explicando su razón, entonces no asuma que sabe mejor que él, especialmente no en una" búsqueda global y reemplazar " manera).

Sin embargo, nadie parece haber señalado el punto de partida más obvio y más rápido de implementar: Vaya a "Debug -> Exceptions" y habilite "Break when exception is thrown" para la sección "Common Language Runtime Exceptions". Esto hará que el depurador se rompa por cada excepción que se lance (antes de que se llame al bloque catch del programa para manejarlo), por lo que ser capaz de probar la aplicación bajo el depurador y determinar qué bloques catch están suprimiendo qué excepciones cuando intenta repetir un error dado, desde el cual puede hacer una llamada de juicio en cuanto a si ese bloque catch en particular tiene o no alguna influencia en el error en cuestión.

Un enfoque que podría tomar para obtener una imagen de lo que está pasando sería tomar cada uno de los bloques vacíos Exception, y hacer que cada uno llame a un método breakOnException(Exception e).

Este método no tiene que hacer nada excepto (por ejemplo) registrarlo. A continuación, puede ejecutar el programa en un depurador con un punto de interrupción en este método y observar si se alcanza el punto de interrupción y, a continuación, investigar las causas. Desafortunadamente eso es un poco intensivo en mano de obra.

¿Tiene pruebas unitarias que se pueden ejecutar contra el código en el depurador ? Tendría sentido hacer lo anterior con estos.