¿Cuál es la mejor estrategia de manejo de excepciones dentro de las clases registro de errores?

Question

Estoy escribiendo un conjunto de registro de errores de las clases que se registro en un archivo, registro de eventos, etc. Lo que el manejo de excepciones debe realizarse dentro de estas clases? Por ejemplo, decir que tengo un método LogError, que se llama de los controladores de excepciones, y escribe en el archivo. Lo que se considera la mejor cosa que hacer, debe producirse un error? Obviamente, yo debería hacer que estos métodos fallan tan seguro como sea posible, pero siempre pueden ocurrir problemas.

Answer 1

En general I de salida en stderr tanta información como sea posible en ese caso, a menudo tanto el error / excepción en el código de registro, y el original de registro / error / excepción. De esta manera existe la posibilidad de reproducir el problema o la comprensión de la misma.

Si la escritura en stderr falla, entonces es el momento de renunciar a -. O bien ignorarlo, para terminar la aplicación por completo

Answer 2

¿Por qué no se utiliza un mecanismo de registro existente, como log4j / log4net / log4php / log4 *? Estas herramientas han probablemente esos detalles resuelto.

Como nota al margen, si ejecuta el código dentro de un recipiente (por ejemplo: Tomcat), incluso si se arroja una excepción dentro del gestor de excepciones del contenedor cogería y mostrarlo. Al igual que Douglas Leeder dijo, puede capturar todas las excepciones dentro del manejador y echarlo a la SYSERR.

Answer 3

Depende lo que el registro es para, si es el registro de depuración Voy a tragar la excepción y mantener porque no quiero que la aplicación falle en la producción debido a las ayudas de depuración, por el contrario si estoy registro en la auditoría log de una aplicación de banca supongo que el cliente va a ser molesto si la aplicación continúan trabajando sin auditoría.

Answer 4

Puede implementar la auditoría y el control de excepciones como servicios. A nivel de aplicación de registro de auditoría requiere datos de estado acerca de cada transacción comercial. La capacidad de supervisar 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ífica a la invocación del servicio. Esto requiere que cada servicio para enviar un mensaje de estado en las etapas decisivas en la transacción comercial. A continuación, puede crear un visor en tiempo real para correlacionar los mensajes de estado (basado 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 de negocios para la gestión de SLA, la localización de errores y la determinación de problemas.

un servicio de auditoría a continuación, puede implementarse como una máquina de estado que puede consumir y grabar mensajes basado en criterios definidos en su configuración. Un gestor de excepciones genérica también puede utilizar el servicio de auditoría para soportar una vista centralizada de los problemas que ocurren en el SOA - para apoyar la vigilancia basada en excepciones. Cualquier condición debe-no-ocurrir en la solución está equipado para enviar un mensaje de excepción a la gestor de excepciones nofollow.