Cuándo comenzar a escribir el manejo de excepciones, el registro

Usted escribe su código de manejo de excepciones cuando escribe algo 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 controla los tiempos de espera de conexión. La excepción es directamente relevante para lo que estás haciendo, y el trabajo está fresco en tu mente.

Por otra parte, si está escribiendo un analizador que genera excepciones cuando encuentra una unidad de datos de protocolo con formato incorrecto, no puede escribir el código de manejo de excepciones para las excepciones que produce el analizador . (Pero, por supuesto, curso estás escribiendo pruebas para mostrar cómo y 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 captura es un buen recordatorio de que las funciones a las que llama pueden fallar, y necesita manejar (si es necesario) esas fallas.

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

En mi experiencia, si no escribe código con el manejo y el registro de errores apropiados desde el principio, no se hará debido a 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 manejaban 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 un sistema de registro". Estos se reducirán en favor de las nuevas características, y como tiene "mucho que hacer", corrija todos los errores en los casos de error en los que no había pensado. (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 crezcan y escríbalos a medida que avanza.

Si está escribiendo algo que necesita rendimiento y tiene una baja posibilidad de errores, le falta un lugar significativo para que los manejadores de errores escriban los manejadores de errores donde las pruebas demuestran que los necesita.

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

para el registro:

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

Aparte de esos casos, generalmente solo agrego el registro en los lugares donde las pruebas / el uso demuestran que es necesario y por lo general hago una opción para configurarlo cuando termine.

Puede implementar la auditoría y el 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 detallan el estado de la transacción específico 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 (según la semántica del mensaje, por ejemplo, el 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 seguimiento de fallas y la determinación de problemas.

Un servicio de auditoría puede implementarse 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 debería ocurrir en la solución está instrumentada para enviar un mensaje de excepción a manejador de excepciones.

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

En otras palabras: haga que sea una manera de manejar esa capacidad de registro, y agregue la funcionalidad real de tuercas y tornillos (qué mensajes registra) más tarde, según sea necesario. En excepciones, agregue la captura (y finalmente si tiene eso) antes de escribir la tirada. Eso ayudará a evitar olvidarse de uno y guardarse una iteración o, en el peor de los casos, un error / bloqueo.