在类库级别捕获 C# 错误

Question

我正在尝试为企业级类库制定错误日志记录解决方案。一些要求：

• 它将被多个端点应用程序使用（因此应该在类库中处理它）
• 它应该将其数据放入 SQL Server 数据库中以便于存储。这也涉及第三个：
• 它应该能够支持自定义 Web 应用程序读取其数据。

还有一个要求，那就是“非常高兴拥有”。也就是说，这并不重要，但如果这不可能，我最好有一个充分的理由。

• 它不应在其端点应用程序中需要专门的 Logger 对象。他们应该能够简单地抛出异常，并且日志记录软件应该从那里处理事情。不过，拥有特定的 USING 命令是正确的。

综合考虑，前三点并不困难。一个快速日志记录类和一些存储过程，中午就到此为止了，对吧？不过，最后一点我不知道如何处理。我以前在朋友的代码中看到过它，所以我知道这是可能的，但不幸的是，他的朋友已经去世了，他的代码已经丢失到了以太中。有没有人可以指出我正确的方向，让类库对象以某种方式捕获端点应用程序出现的所有错误来处理它们？

Answer 1

如果您想捕获并非源自您自己的调用堆栈的所有未处理的异常，您可以考虑利用 AppDomain 对象：

AppDomain.CurrentDomain.UnhandledException += (s, e) => {
    // Your logging logic
};

AppDomain.CurrentDomain.FirstChanceException += (s, e) => {
    // Your logging logic
};

Answer 2

听起来 Microsoft Enterprise Library 可以在这里使用...

http://msdn .microsoft.com/en-us/library/ff649552.aspx

Answer 3

当我阅读企业级类库时，我脑海中浮现出这些要求：

• 您的组件不应抛出异常并干扰系统。
• 它应优雅地处理错误并能够从错误中恢复。

对于作为开发人员的您来说，在睡觉前，这些要求是一本很好的读物。所有的错误场景，甚至是你最疯狂的梦想中的错误场景，迟早都会成为现实，你会在半夜凌晨 3 点尖叫着醒来。

这些要求听起来不错，但其影响是深远的。如果您尝试捕获组件中的所有错误，那么您除了隐藏错误之外什么也不做。这样的系统往往很慢，有时它们只是停止工作，没有人知道为什么，因为一些后续错误确实使系统进入了一种实际上什么都不起作用的状态。可悲的是，如果您将调试器附加到那台陈旧的机器上，您将看不到导致问题的原始错误，而是看到后续问题，您必须向后工作到原始问题。如果您想登录到 SQL Server，我可以向您保证，您最终会经常遇到没有日志或丢失日志的情况。

您应该考虑更可靠的日志目的地（自定义事件日志、日志文件……或两者）。并且不惜一切代价避免异步日志记录，因为未处理的异常会比您在日志记录线程中记录它的速度更快地导致进程崩溃。

实际上，当发生致命错误时，您需要尽早停止系统。可以在不破坏状态的情况下安全恢复的错误通常很少，但它们是值得付出努力的，因为您需要将类库设计为健壮的（处理预期错误）和安全的（抛出异常，记录它们，... ）。

在设计阶段，更容易想到一个可以应对所有错误的完美系统。软件架构师喜欢这样的系统。他们可以侥幸逃脱，因为从纸面上看，它看起来不错。或者换句话说：泡沫不会破裂。

但是在执行时，您的类库正在使用

• 真实物理内存（OutOfMemoryException）
• 真实硬盘空间（至少日志文件）（硬盘已满）
• 真实CPU周期（100％CPU）
• 真实堆栈空间（StackOverFlowException）

如果您尝试隐藏致命错误错误，系统只会变得更难调试，但它仍然会失败，因为您的库将消耗不完全属于您的组件的共享资源。在这种情况下，最好立即停止工作，而不是继续工作而让其他人也失败。

隐藏组件内部所有错误的想法是有缺陷的，因为您无法防止组件内部的致命错误影响系统中的其他组件。

那只蜜蜂说，我希望您不要问如何捕获类库级别的所有错误，而是在您的端点应用程序中向用户显示错误并记录它们（希望只在每一层一次而不是再次出现，因为您不信任其他层）。正如其他人指出的那样，您可以获取未处理的异常，这些异常确实终止了一个线程，当您的错误处理程序离开时，该线程又会终止您的进程。除此之外，最好在 Main 方法周围放置一个 try/catch 块以捕获主线程中的错误。如果您的应用程序有 UI（Windows 窗体），您还应该注册 Application.ThreadException 事件，当异常从 Window 消息处理程序传播出去时，该事件将被调用。

你的，
阿洛伊斯·克劳斯