我正在编写一组错误日志记录类，这些类将记录到文件、事件日志等。在这些类中应该执行什么异常处理？ 例如，假设我有一个 LogError 方法，该方法从异常处理程序调用并写入文件。 如果发生错误，什么被认为是最好的做法？ 显然，我应该使这些方法尽可能安全，但问题总是会发生。
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.
发布评论
评论（4）
一般来说，在这种情况下，我会向 stderr 输出尽可能多的信息，通常是日志记录代码中的错误/异常，以及原始日志/错误/异常。 这样就有机会重现问题或理解问题。
如果写入 stderr 失败，那么就该放弃了 - 要么忽略它，要么完全终止应用程序。
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.
为什么不使用现有的日志记录机制，例如 log4j/log4net/log4php/log4*？ 这些工具可能已经整理好了这些细节。
附带说明一下，如果您在容器（例如：tomcat）内运行代码，即使您在异常处理程序内抛出异常，容器也会捕获它并显示它。 就像 Douglas Leeder 所说，您可以捕获处理程序内的所有异常并将其抛出到 syserr。
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.
这取决于日志记录的用途，如果是调试日志记录，我将吞下异常并继续，因为我永远不希望应用程序由于调试辅助而在生产中失败，另一方面，如果我记录到审计日志银行应用程序 我想如果应用程序在未经审核的情况下继续运行，客户会感到不安。
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.
您可以将审计和异常处理作为服务来实现。 应用程序级审计日志记录需要有关每个业务事务的状态数据。 在业务或事务上下文中监视应用程序的能力需要服务内的监视接口来发送详细说明特定于服务调用的事务状态的消息。 这要求每个服务在业务事务的关键步骤发送状态消息。 然后，您可以构建一个实时查看器，将状态消息（基于消息的语义，例如事务 ID）与组合应用程序中的服务关联起来。 这为 SLA 管理、故障跟踪和问题确定提供了业务事务的端到端视图。
然后，审计服务可以实现为状态机，可以根据其配置中定义的标准使用和记录消息。 通用异常处理程序还可以使用审计服务来支持企业 SOA 中发生的问题的集中视图，以支持基于异常的监控。 解决方案中任何不应该发生的情况都会被检测以将异常消息发送到 异常处理程序。
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.