c# - 如何处理 AppDomain.Unload 和相关的 ThreadAbortException

Question

根据 MSDN，AppDomain.Unload 会导致卸载 AppDomain 内的所有线程抛出线程中止异常。

The threads in domain are terminated using the Abort method, which throws a ThreadAbortException in the thread. Although the thread should terminate promptly, it can continue executing for an unpredictable amount of time in a finally clause. -- from MSDN

所以我的理解是，每次我在任何地方编写预期在此 AppDomain 中运行的代码时，我都必须预料到线程中止可能随时在任何线程上发生。这是真的？ 所有代码是否都应该假设 ThreadAbortException 可以随时抛出？

实际上这实际上消除了 catch(Exception ex) 因为这会捕获 ThreadAbortException 并尝试处理它，通常是通过记录一个实际上不应该记录的错误(因为卸载 AppDomain 不是'这真的是个异常(exception))。

是否需要采取任何其他注意事项来避免不必要的异常处理/错误记录？

Answer 1

您对任何时候发生 TAE 的可能性的预期几乎都是正确的。我要说的唯一一点是，您的代码可能应该已经以这种方式编写 - 在处理具有可靠性要求的数据时，您应该在硬件故障、运算符(operator)错误、OOM 等情况下使用事务或其他补偿机制 - 任何其中并非 AppDomain 关闭的场景所独有。

最后，您应该知道您可以捕获 TAE 并在 catch block 中执行补偿代码。它们唯一的特别之处在于它们会在 catch block 之后立即被重新抛出，所以你不能“吞下”它们。您可以使用 Thread.ResetAbort() 来抑制它们，但在这种情况下，这可能不是预期的效果。

我们都写过这样的代码:

public void Foo() {
    try {
        Do.Some.Stuff();
    } catch (Exception ex) {
       Console.Out.WriteLine("Oh noes!");
    }
}

是的，catch block 将捕获所有内容¹，包括 TAE 和 OOM。

这里要记住的是，对于上述所有异常(exception)情况，世界基本上已经结束了。您应该关心的是，您正在处理的任何事务敏感数据都不会丢失或处于不良状态，这就是为什么我们通常将事务安全 I/O 之类的事情留给 Microsoft 和 Oracle 的聪明人谁写数据库。例如，如果您的代码正在执行平面文件 I/O，您需要非常确定永远不会让文件处于不良状态，那么您应该以非常全面的方式考虑故障模式- 比如“如果这个文件写到一半就断电了怎么办？”

¹ 唯一的异常(exception)是 StackOverflow exceptions generally cannot be caught .这是 .NET 2.0 中的更改。