What is the best exception handling strategy within error logging classes?

Question

I am writing an error logging set of classes which will log to file, event log etc. What exception handling should be performed within these classes? For instance, say I have a LogError method, which is called from exception handlers, and writes to file. What is considered the best thing to do, should an error occur? Obviously, I should make these methods as fail safe as possible, but problems can always occur.

Answer 1

Generally I output to stderr as much information as possible in that case, often both the error/exception in the logging code, and the original log/error/exception. That way there's a chance of reproducing the problem or understanding it.

If writing to stderr fails then it's time to give up - either ignore it, to terminate the application entirely.

Answer 2

Why don't you use an existing logging mechanism such as log4j/log4net/log4php/log4*? These tools probably have those details sorted out.

As a side note, if you run your code inside a container (eg: tomcat) even if you throw an exception inside the exception handler the container would catch it and show it. Like Douglas Leeder said, you can catch all exceptions inside the handler and throw it to the syserr.

Answer 3

It depends what the logging is for, if it's debug logging I'll swallow the exception and continue because I never want the application to fail in production due to debugging aids, on the other hand if I'm logging to the audit log of a banking application I guess the customer is going to be upset if the application continue to work without auditing.

Answer 4

You can implement auditing and exception handling as services. Application-level audit logging requires status data about each business transaction. The ability to monitor an application in a business or transactional context requires a monitoring interface within the service to send messages detailing the transaction's status specific to the service invocation. This requires each service to send a status message at critical steps in the business transaction. You can then build a real-time viewer to correlate status messages (based on the semantics of the message - e.g. transaction ID) with the services within the composite application. This provides an end-to-end view of the business transaction for SLA management, fault tracing and problem determination.

An audit service can then be implemented as a state machine that can consume and record messages based on criteria defined in its configuration. A generic exception handler can also use the audit service to support a centralized view of problems that occur in the enterprise SOA - to support exception-based monitoring. Any should-not-occur condition in the solution is instrumented to send an exception message to the exception handler.