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

Question

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

域中的线程使用Abort方法终止,该方法在线程中抛出ThreadAbortException.虽然线程应该立即终止,但它可以在finally子句中继续执行不可预测的时间量.- 来自MSDN

所以我的理解是每次我在任何预期在这个AppDomain中运行的代码编写代码时,我都不得不期望任何线程都可以随时发生线程中止.这是真的？所有代码都应该假设可以随时抛出ThreadAbortException吗？

实际上这实际上是elimates catch(Exception ex),因为它会捕获ThreadAbortException并尝试处理它,通常是通过记录一个真的不应该记录的错误(因为卸载AppDomain实际上不是一个例外).

是否还需要考虑其他因素以避免不必要的异常处理/错误记录？

Answer 1

你几乎可以随时了解TAE的可能性.我要做的唯一一点是你的代码应该已经用这种方式编写了 - 当处理具有可靠性要求的数据时,你应该在硬件故障,操作员错误,OOM等情况下使用事务或其他补偿机制 - 任何其中不是AppDomain关闭方案所特有的.

最后,您应该知道可以捕获TAE并在catch块中执行补偿代码.关于他们的唯一特别之处在于它们会在捕获块后立即重新生成,因此您无法"吞下"它们.您可以通过使用来抑制它们Thread.ResetAbort(),但在这种情况下可能不是所需的效果.

我们都编写了这样的代码:

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

是的,catch块将捕获所有内容¹,包括TAE和OOM.

这里要记住的是,对于上述所有例外情况,世界基本上都已结束.您应该关心的是,您正在处理的任何事务敏感数据都不会丢失或处于错误状态,这就是为什么我们通常会将事务安全I/O等内容留给Microsoft和Oracle的智能人员谁写数据库.例如,如果您的代码正在执行平面文件I/O,您需要确保它永远不会使文件处于错误状态,那么您应该以非常全面的方式考虑故障模式 - 例如"如果当这个文件被写下来时,电源会消失吗？"

¹唯一的例外是StackOverflow异常通常无法捕获.这是.NET 2.0的一个变化.