Cuándo comenzar a escribir Manejo de excepciones, registro

¿Cuándo comienza a escribir su Código de manejo de excepciones? ¿Cuándo comienza a escribir declaraciones de registro?

Con el propósito de elaborar esta pregunta, supongamos que estamos en la plataforma .NET con el registro log4net, pero no dude en responder de manera genérica.

Solución: un proyecto de formularios Windows Forms. Proyectos: UI, BusinessRules, DataHandlers

Entonces, ¿vas a escribir tus DataHandlers que hacen tus manipulaciones de datos como Crear, Leer, Actualizar, Eliminar primero.

Luego siga con sus Reglas de Negocio

Y luego su interfaz de usuario o cualquier otra permutación de lo anterior.

Pon a prueba tu aplicación para la funcionalidad.

¿Y luego comienza a escribir su Código de manejo de excepciones y finalmente su código de registro?

¿Cuándo es el momento adecuado para comenzar a escribir su código de manejo de excepciones?

PD: En el libro Clean Code , dicen Escribe primero tu bloque try-catch-finally . Eso me llevó a hacer esta pregunta.

Usted escribe su código de manejo de excepciones cuando escribe lo que llama a algo que podría causar excepciones.

Por ejemplo, cuando escribe algo que envía datos a una red, también debe escribir el código que maneja los tiempos de espera de conexión. La excepción es directamente relevante para lo que está haciendo, y el trabajo está fresco en su mente.

Por otro lado, si está escribiendo un analizador que genera excepciones cuando encuentra una unidad de datos de protocolo con formato incorrecto, entonces no puede escribir código de manejo de excepciones para las excepciones que produce el analizador . (¡Pero, por supuesto , está escribiendo pruebas para mostrar cómo, cuándo y por qué el analizador genera excepciones!)

La razón detrás de la sugerencia de escribir su try-catch-finally primero es doble: finalmente es para limpiar los recursos que la función crea / consume, y escribir el catch es un buen recordatorio de que las funciones que está llamando pueden fallar, y necesita manejar (si es necesario) esas fallas.

Tiendo a agregar registros después del hecho. No estoy seguro de si eso es sabio, pero es lo que me ha funcionado. Cuando empiezo a ejecutar pruebas de aceptación y cosas similares, y empiezo a resolver problemas, agrego el registro para poder rastrear errores. (Y luego dejo el inicio de sesión).

En mi experiencia, si no escribe código con el manejo y registro de errores apropiados desde el principio, no se realizará debido a las presiones de tiempo. Los esfuerzos de desarrollo más exitosos en los que he estado comenzaron con el tiempo dedicado a determinar la estructura básica de la aplicación, incluido el estándar de codificación, cómo se manejarían los errores, el registro, la arquitectura básica y las herramientas de prueba.

De lo contrario, encontrará que tiene tareas para la versión 2.0 como "Mejorar el manejo de errores" y "crear sistema de registro". Estos se eliminarán en favor de las nuevas funciones y, debido a que tiene "demasiado para hacer", reparará todos esos errores en los casos de error en los que no pensó. (Lo que lleva una eternidad, porque no tiene un sistema de registro.

Depende de lo que estés haciendo

para excepciones:

Si está escribiendo algo que es probable que tenga errores o algo en el que haya buenos puntos de nivel superior para que las excepciones surjan para escribirlos a medida que avanza.

Si está escribiendo algo que necesita rendimiento y tiene una baja posibilidad de errores, carece de un lugar significativo para colocar los controladores de errores, escriba los controladores de errores donde las pruebas prueben que los necesita.

En cualquier caso, si no tiene nada útil que hacer con el error, considere dejarlo burbujear (sin controlador)

para iniciar sesión:

Si necesita una pista de auditoría, primero debe escribir el registro. Si está dejando que los errores lleguen a la cima, debe proporcionar un registro allí también para que se pueda capturar el registro.

Aparte de esos casos, generalmente solo agrego el registro en los lugares donde las pruebas / uso prueban que es necesario y, por lo general, hago una opción para configurarlo una vez que haya terminado con él.

Puede implementar auditorías y manejo de excepciones como servicios. El registro de auditoría a nivel de aplicación requiere datos de estado sobre cada transacción comercial. La capacidad de monitorear una aplicación en un contexto comercial o transaccional requiere una interfaz de monitoreo dentro del servicio para enviar mensajes que detallen el estado de la transacción específica a la invocación del servicio. Esto requiere que cada servicio envíe un mensaje de estado en los pasos críticos de la transacción comercial. Luego, puede crear un visor en tiempo real para correlacionar los mensajes de estado (basados ​​en la semántica del mensaje, por ejemplo, ID de transacción) con los servicios dentro de la aplicación compuesta. Esto proporciona una vista de extremo a extremo de la transacción comercial para la gestión de SLA, el rastreo de fallas y la determinación de problemas.

Un servicio de auditoría se puede implementar como una máquina de estado que puede consumir y grabar mensajes según los criterios definidos en su configuración. Un controlador de excepciones genérico también puede usar el servicio de auditoría para admitir una vista centralizada de los problemas que ocurren en la SOA de la empresa, para admitir la supervisión basada en excepciones. Cualquier condición que no ocurra en la solución está instrumentada para enviar un mensaje de excepción al controlador de excepciones.

Escríbalo cuando lo necesite, pero diseñe para su inclusión desde el principio.

En otras palabras: haga que haya una manera de manejar esa capacidad de registro, y agregue la funcionalidad real de tuercas y tornillos (qué mensajes registra) más tarde cuando surja la necesidad. En excepciones, agregue la captura (y, finalmente, si la tiene) antes de escribir el lanzamiento. Eso ayudará a evitar olvidar uno y ahorrarse una iteración o, en el peor de los casos, un error / bloqueo.