.net - 错误记录类中最好的异常处理策略是什么？

Question

我正在编写一组错误日志记录类，这些类将记录到文件、事件日志等。应该在这些类中执行哪些异常处理？例如，假设我有一个 LogError 方法，该方法从异常处理程序中调用，并写入文件。如果发生错误，什么被认为是最好的做法？显然，我应该使这些方法尽可能安全，但问题总是会发生。

Answer 1

通常，在这种情况下，我会向 stderr 输出尽可能多的信息，通常是日志代码中的错误/异常以及原始日志/错误/异常。这样就有机会重现或理解问题。

如果写入 stderr 失败，那么是时候放弃了——要么忽略它，要么完全终止应用程序。

Answer 2

为什么不使用现有的日志记录机制，例如 log4j/log4net/log4php/log4*？这些工具可能已经整理了这些细节。

作为旁注，如果您在容器（例如：tomcat）中运行代码，即使您在异常处理程序中抛出异常，容器也会捕获并显示它。就像 Douglas Leeder 所说，您可以在处理程序中捕获所有异常并将其扔给 syserr。

Answer 3

这取决于日志记录的用途，如果是调试日志记录，我将吞下异常并继续，因为我不希望应用程序由于调试辅助而在生产中失败，另一方面，如果我正在记录到审计日志银行应用程序 我猜如果应用程序在没有审计的情况下继续工作，客户会感到不安。

Answer 4

您可以将审计和异常处理实现为服务。应用程序级审计日志需要有关每个业务事务的状态数据。在业务或事务上下文中监视应用程序的能力需要服务中的监视接口来发送详细说明特定于服务调用的事务状态的消息。这要求每个服务在业务事务的关键步骤中发送状态消息。然后，您可以构建一个实时查看器，将状态消息（基于消息的语义——例如事务 ID）与复合应用程序中的服务关联起来。这为 SLA 管理、故障跟踪和问题确定提供了业务事务的端到端视图。

然后可以将审计服务实现为状态机，该状态机可以根据其配置中定义的标准来使用和记录消息。通用异常处理程序还可以使用审计服务来支持企业 SOA 中出现的问题的集中视图 - 以支持基于异常的监视。解决方案中的任何不应该发生的条件都被检测为向异常处理程序发送异常消息。