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服务器，我可以向您保证，您最终会经常没有或丢失日志。

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

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

在设计阶段，更容易想到一个能够应对所有错误的完美系统。像这样的系统的软件架构师。他们可以逃脱它，因为在纸面上看起来不错。换句话说：泡泡不会崩溃。

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

真实物理内存（OutOfMemoryException）
真实硬盘空间（至少是日志文件）（硬盘已满）
实际CPU周期（100％CPU）
Real Stack Space（StackOverFlowException）

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

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

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

此致， Alois Kraus

在类库级别捕获C＃错误

3 个答案: