在WCF中处理线程异常

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

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

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

我知道System.Windows.Forms应用程序可以通过实现

Application.ThreadException

来处理线程异常。我能从WCF服务中做些类似的事情吗？或者，如果

Application.ThreadException

是一种方法，我将如何从WCF服务连接它

AppDomain.UnhandledException

的MSDN文档说它不能防止崩溃。

ServiceModel.AsynchronousThreadExceptionHandler的文档建议它仅适用于WCF线程

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

再次强调，我不想将此异常作为WCF故障返回给客户端。
因为您不知道异常的原因，所以唯一明智的做法是崩溃。您不知道服务处于什么状态，如果继续，可能会使情况变得更糟

请记住，IIS将为您重新启动服务、清理并可能正常工作。
如果您正在生成线程，则应始终确保它们具有异常保护。针对未处理异常的AppDomain处理只提供了一种记录和跟踪错误的方法，但它不会阻止主机崩溃。
您可以看看使用分派行为实现IErrorHandler：

请说出否决票的原因。如果不知道问题出在哪里，答案就不可能得到改善。我同意这一点。。。如果您有一个预期的异常，您应该在接近其原点的地方处理它。如果这是意外的，它应该允许应用程序崩溃。我们的工作线程中的代码不会做任何疯狂的事情，这会让东西处于未知状态。除非IIS本身可能被摧毁，否则我宁愿不崩溃。我宁愿把这个问题记录下来，然后继续下去。（请注意，我没有否决任何投票。）你今天可能没有做任何疯狂的事情，但你，或.NET，或你称之为的东西，明天可能会这样做。所有这些线程都在相同的AppDomain中，处于相同的进程中；由于共享内存或其他共享资源，导致一个线程死亡的原因很可能会导致另一个线程失败。这是真的。那么，您建议在进程结束之前使用AppDomain.UnhandledException记录原始异常吗？是的，我希望每个人都能用高级try/catch包装线程方法。如何在WCF服务中连接AppDomain.UnhandledException处理程序？您需要在域启动期间执行此操作。如果您有自定义主机，则可以在启动代码中，如果您在IIS中（如在常规asp.net应用程序中）托管，则可以在Global.asax中。