在 WCF 中处理线程异常答案

【问题标题】：Handling Thread Exceptions in WCF在 WCF 中处理线程异常
【发布时间】：2009-07-10 16:32:53
【问题描述】：

我们的 WCF 服务偶尔会产生一个工作线程来处理客户端不关心的事情。工作线程不会向客户端报告任何状态。事实上，在线程结束时，服务可能已经将结果返回给客户端。

其中一个后台线程最近引发了异常。异常未处理，因此 IIS 崩溃。

我可以修复这个特定的异常，但是将来有人可能会添加一些导致另一个意外异常的代码。我想防止这种情况在将来使 IIS 崩溃。

我知道 System.Windows.Forms 应用可以通过实现Application.ThreadException 来处理线程异常。我可以从 WCF 服务中做类似的事情吗？或者如果Application.ThreadException 是要走的路，我将如何从 WCF 服务中连接它？

AppDomain.UnhandledException 的 MSDN 文档说它不能防止崩溃。 ServiceModel.AsynchronousThreadExceptionHandler 的文档建议它仅适用于 WCF 线程。

至少，我想在崩溃之前从异常中获取堆栈跟踪，但完全避免未来的崩溃将是理想的。

再次强调，这不是我想作为 WCF 错误返回给客户端的异常。

【问题讨论】：

【解决方案1】：

由于您不知道导致异常的原因，唯一明智的做法是崩溃。您不知道服务处于什么状态，继续下去可能会使事情变得更糟。

请记住，IIS 将为您重新启动服务，干净且可能正常工作。

【讨论】：

请说出拒绝投票的原因。如果不知道问题出在哪里，答案就不可能得到改善。
我同意这一点...如果您有预期的异常，您应该在接近其起源的地方处理它。如果发生意外，它应该允许应用程序崩溃。
我们在工作线程中的代码不会做任何让事情处于未知状态的疯狂事情。除非 IIS 本身可能被重击，否则我宁愿不崩溃。我宁愿记录这个问题并让它继续下去。（请注意，我没有投反对票。）
你今天可能没有做任何疯狂的事，但你，或 .NET，或你所称的东西，明天可能会这样做。所有这些线程都在同一个 AppDomain 中，在同一个进程中；由于共享内存或其他共享资源，导致一个线程死亡的任何原因都可能导致另一个线程失败。
确实如此。那么你会推荐使用 AppDomain.UnhandledException 在进程终止之前记录原始异常吗？

【解决方案2】：

如果您正在生成线程，您应该始终确保它们具有异常防护。 AppDomain 对未处理异常的处理仅提供了一种记录和跟踪错误的方法，但它不会阻止主机崩溃。

【讨论】：

是的，我希望每个人都会用高级 try/catch 来包装线程方法。如何在 WCF 服务中连接 AppDomain.UnhandledException 处理程序？
您需要在域启动期间执行此操作。如果您有自定义主机，这可能是您的启动代码中的某些内容，或者如果您在 IIS 中托管，则可能在您的 Global.asax 中，例如在常规的 asp.net 应用程序中。

【解决方案3】：

您可以看看使用 Dispatch Behavior 实现 IErrorHandler：

【讨论】：