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块抛出）。当cryptoStream.Dispose()调用StreamReader时，会引发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块会导致异常终止运行时。

我确定问题就在这里

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

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

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

问题

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

由于从封闭的finally块抛出CryptographicException异常，ArgumentException如何终止，因为删除catch (CryptographicException)块会导致异常无法处理终止运行时？
由于运行时似乎在CryptographicException块出现时处理catch (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个不同的阶段：

第1阶段一旦执行throw语句就会启动。 CLR寻找一个范围内的catch块，它宣告它愿意处理异常。在此阶段，在C＃中，没有代码执行。从技术上讲，可以执行代码，但该功能不会在C＃中公开。
找到catch块后，阶段2开始，CLR知道恢复执行的位置。然后，它可以可靠地确定最终需要执行的块。任何方法堆栈帧也都被解开了。
阶段3在所有finally块完成后开始，并且堆栈被展开到包含catch语句的方法。指令指针设置为catch块中的第一个语句。如果此块不包含进一步的throw语句，则执行将在catch块之后的语句处恢复正常。

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

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

Answer 2

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

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

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

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

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

但是，您只能通过显式使用finally来达到此状态，因此我相信您假设您正在考虑此期望或可能性（正如您使用{{1那时，这意味着你已经接受了你可能有一个例外）。

try中的规范基本上对此进行了详细说明（您引用的8.9.5中的文字引用了此部分）：

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

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

Answer 3

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

事实是，规范是有道理的，而行为则不然。当您在较旧的运行时中运行代码时，情况会更加明显，其中完全不同......或者至少出现。

快速回顾

我在x64 Win7机器上看到的内容：

.NET v2.0-3.5 - 抛出CryptographicException时的WER对话框。点击Close the program后，程序继续，好像从未抛出过这样的执行。该应用程序未终止。这是阅读规范所期望的行为，以及在.NET中实现异常处理的is well defined by the architects。
.NET v4.0-4.5 - 不显示WER对话框。而是会出现一个窗口，询问您是否要调试该程序。单击no会导致程序立即终止。之后没有执行finally块。

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

这绝不是你期望的

谁会怀疑及时调试程序？

你可能已经注意到在.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一样。

Running in .NET 4.0

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

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

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

代码

更多信息

我确定问题就在这里

问题

额外信息编辑

3 个答案:

快速回顾

这绝不是你期望的