当从finallys抛出异常时，不会评估Catch块

Question

出现这个问题是因为以前在.NET 4.0中运行的代码在.NET 4.5中出现了未处理的异常，部分原因是try / finallys。 如果您需要详细信息，请阅读Microsoft connect 。 我用它作为这个例子的基础，所以它可能有助于引用。

代码

对于那些选择不阅读这个问题背后细节的人来说，这里可以快速了解发生这种情况的条件：

using(var ms = new MemoryStream(encryptedData))
using(var cryptoStream = new CryptoStream(encryptedData, decryptor, CryptoStreamMode.Read))
using(var sr = new StreamReader(cryptoStream))

这个问题是从CryptoStream的Dispose方法抛出异常（因为它们在using语句中，这些异常碰巧从两个不同的finally块抛出）。 当StreamReader调用cryptoStream.Dispose() ，将抛出CryptographicException 。 第二次cryptoStream.Dispose() ，在其using语句中，它抛出一个ArgumentNullException

下面的代码从上面提供的链接中删除了大部分不必要的代码，并将using语句展开到try / finallys中，以清楚地表明它们正在抛出finally块。

using System;
using System.Security.Cryptography;
namespace Sandbox
{
    public class Program
    {
        public static void Main(string[] args)
        {
            try
            {
                try
                {
                    try
                    {
                        Console.WriteLine("Propagate, my children");
                    }
                    finally
                    {
                        // F1
                        Console.WriteLine("Throwing CryptographicExecption");
                        throw new CryptographicException();
                    }
                }
                finally
                {
                    // F2
                    Console.WriteLine("Throwing ArgumentException");
                    throw new ArgumentException();
                }
            }
            catch (ArgumentException)
            {
                // C1
                Console.WriteLine("Caught ArgumentException");
            }
            // Same behavior if this was in an enclosing try/catch
            catch (CryptographicException)
            {
                // C2
                Console.WriteLine("Caught CryptographicException");
            }

            Console.WriteLine("Made it out of the exception minefield");
        }
    }}

注意：try / finally对应于引用代码中的扩展using语句。

输出：

Propagate, my children
    Throwing CryptographicExecption
    Throwing ArgumentException
    Caught ArgumentException
    Press any key to continue . . .

似乎没有执行CryptographicException catch块。 但是，删除该catch块会导致异常终止运行时。

更多信息

编辑：这已更新为规范的最新版本。 我碰巧抓住MSDN的那个用了较旧的措辞。 Lost已更新为已terminated 。

深入了解C＃规范，第8.9.5节和第8.10节讨论了异常行为：

• 当抛出异常时，包括来自finally块内部的异常，控制转移到封闭的try语句中的第一个catch子句。 这将继续尝试语句，直到找到合适的语句。
• 如果在执行finally块期间抛出异常，并且已经传播了异常，则终止该异常

“终止”使得看起来第一个异常将永远被第二个抛出的异常隐藏，尽管它似乎不是正在发生的事情。

我确定这个问题就在这里

在大多数情况下，可以很容易地看到运行时正在做什么。 代码执行到第一个finally块（ F1 ），其中抛出异常。 随着异常传播，从第二个finally块（ F2 ）抛出第二个异常。

根据规范，从F1抛出的CryptographicException现在终止，运行时正在寻找ArgumentException的处理程序。 运行时找到一个处理程序，并在catch块中为ArgumentException （ C1 ）执行代码。

这里有雾：规范说第一个例外将被终止。 但是，如果从代码中删除了第二个catch块（ C2 ），则假定丢失的CryptographicException现在是一个未处理的异常，它终止了该程序。 在存在C2 ，代码不会从未处理的异常终止，因此从表面上看它似乎正在处理异常，但是块中的实际异常处理代码永远不会被执行。

问题

问题基本相同，但针对特异性进行了重新措辞。

1. 由于从封闭的finally块抛出ArgumentException异常， CryptographicException是如何终止的，因为删除catch (CryptographicException)块会导致异常无法处理并终止运行时？

2. 由于运行时似乎在catch (CryptographicException)块存在时处理CryptographicException ，为什么块内的代码没有执行？

---

额外的信息编辑

我仍然在研究这个问题的实际行为，并且许多答案在至少回答上述问题的部分内容时特别有帮助。

另一个奇怪的行为是，当您运行带有catch (CryptographicException)块的代码注释掉时，这是.NET 4.5和.NET 3.5之间的区别。 .NET 4.5将抛出CryptographicException并终止应用程序。 但是，.NET 3.5似乎表现得更符合C＃规范中的异常。

Propagate, my children
Throwing CryptographicExecption

Unhandled Exception: System.Security.Cryptography.CryptographicException [...]
ram.cs:line 23
Throwing ArgumentException
Caught ArgumentException
Made it out of the exception minefield

在.NET 3.5中，我看到了我在规范中读到的内容。 异常变为“丢失”或“终止”，因为唯一需要捕获的是ArgumentException 。 因此，程序可以继续执行。 我的机器上只有.NET 4.5，我想知道这是否发生在.NET 4.0中？

Answer 1

.NET中的异常处理有3个不同的阶段：

• 一旦throw语句执行，第1阶段就会启动。 CLR正在寻找一个范围内的catch块，它宣告它愿意处理异常。 在这个阶段，在C＃中， 没有代码执行 。 从技术上讲，可以执行代码，但该功能不会在C＃中公开。

• 找到catch块后，阶段2开始，CLR知道恢复执行的位置。 然后，它可以可靠地确定最终需要执行的块。 任何方法堆栈帧也都被解开。

• 一旦所有finally块完成并且堆栈被展开到包含catch语句的方法，则阶段3开始。 指令指针设置为catch块中的第一个语句。 如果此块不包含进一步的throw语句，则执行将在catch块之后的语句处恢复正常。

因此，代码片段中的核心要求是范围内存在catch（CryptographicException）。 没有它，第1阶段失败，CLR不知道如何恢复执行。 线程已死，通常还会根据异常处理策略终止程序。 finally块中没有一个会执行。

如果在阶段2中，finally块抛出异常，则立即中断正常的异常处理序列。 最初的异常是“丢失”，它永远不会进入第3阶段，因此无法在您的程序中观察到。 异常处理从第1阶段开始，现在正在查找新异常并从该finally块的范围开始。

Answer 2

如果在执行finally块期间抛出异常，并且已经传播了异常，则该异常将丢失

基本上，执行时会发生什么：

• 内部最后抛出CryptographicException 。
• 外部作用域最终执行，并抛出ArgumentException 。 由于“CryptographicException”在这个时间点被“传播”，它就会丢失。
• 发生最终捕获，并捕获ArgumentException 。

......并且第一个例外简单地消失在以太中是没有意义的，只是因为从另一个finally块抛出了另一个异常。

这正是基于您引用的C＃语言规范所发生的情况。 第一个例外（ CryptographicException ）实际上消失了 - 它“丢失”了。

但是，你只能通过显式使用finally来达到这种状态，所以我相信你假设你正在考虑这种期望或可能性提供错误处理（因为你在那时使用try ，这意味着你已经接受你可能有例外）。

这基本上在8.9.5中的规范中详细解释（您引用的8.10的文字引用了本节）：

如果finally块抛出另一个异常，则终止当前异常的处理。

第一个例外，在你的情况下ArgumentException ，基本上“消失”。

Answer 3

事实证明，我并不疯狂。 基于我对这个问题的回答，我认为我似乎很难理解规范中如此清晰概述的内容。 这根本不是很难掌握。

事实是，规范是有道理的，而行为则不然。 当您在较旧的运行时中运行代码时，情况会更加如此，在该运行时，它的行为完全不同......或者至少看起来如此 。

快速回顾一下

我在x64 Win7机器上看到了什么：

• .NET v2.0-3.5 - 抛出CryptographicException时的WER对话框。 点击Close the program ，程序继续执行，就像从未抛出execption一样。 申请未终止 。 这是阅读规范时所期望的行为，并且由在.NET中实现异常处理的架构师很好地定义 。

• .NET v4.0-4.5 - 不显示WER对话框。 而是会出现一个窗口，询问您是否要调试该程序。 单击no会导致程序立即终止。 之后没有执行finally块。

事实证明，几乎所有试图回答我问题的人都会得到与我相同的结果，这就解释了为什么没人能回答我为什么运行时终止于它吞下的异常的问题。

它永远不会像你期望的那样

谁会怀疑Just-In-Time调试器 ？

你可能已经注意到在.NET 2下运行应用程序会产生一个与.NET 4不同的错误对话框。但是，如果你像我一样，你会在开发周期中期待那个窗口，所以你没有想想它的一切。

vsjitdebugger可执行文件强制终止应用程序，而不是让它继续。 在2.0运行时， dw20.exe没有这种行为，事实上，你看到的第一件事是WER消息。

由于jit调试器终止了应用程序，它使得它似乎不符合规范所说的，事实上它确实如此。

为了测试这一点，我通过将HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug\\Auto的注册表项从1更改为0来禁用vsjitdebugger启动失败。果然，应用程序忽略了异常并继续，就像.NET 2.0一样。

---

事实证明，有一种解决方法，但由于您的应用程序正在终止，因此没有理由解决此问题。

1. 弹出Just-In-Time调试器窗口时，选中Manually choose the debugging engines ，然后单击是，您要调试。
2. 当Visual Studio为您提供引擎选项时，单击取消。
3. 这将导致程序继续，或者弹出WER对话框，具体取决于您的机器配置。 如果发生这种情况，告诉它关闭程序实际上不会关闭它，它将继续运行，好像一切都好。