17

这个问题的出现是因为以前在 .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))

这个问题是DisposeCryptoStream 的方法抛出了异常(因为它们在 using 语句中,这些异常恰好是从两个不同的 finally 块中抛出的)。当cryptoStream.Dispose()被 调用时StreamReaderCryptographicException被抛出。第二次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 语句。

输出:

    传播,我的孩子们
    抛出 CryptographicExecption
    抛出参数异常
    捕获的参数异常
    按任意键继续 。. .

似乎CryptographicException从未执行过 catch 块。但是,删除该 catch 块会导致异常终止运行时。

更多信息

编辑:这已更新为规范的最新版本。我碰巧从 MSDN 上抢到的那个有更旧的措辞。 Lost已更新为terminated.

深入了解 C# 规范,第 8.9.5 和 8.10 节讨论异常行为:

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

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

我确定问题就在这里

在大多数情况下,很容易可视化运行时在做什么。代码执行到F1抛出异常的第一个 finally 块 ( )。随着异常的传播,第二个异常从第二个 finally 块 ( F2) 中抛出。

根据规范,CryptographicException抛出的 fromF1现在已终止,运行时正在寻找ArgumentException. ArgumentException运行时找到一个处理程序,并为( )执行 catch 块中的代码C1

这是它变得模糊的地方:规范说第一个异常将被终止。C2但是,如果从代码中删除CryptographicException第二个 catch 块(就C2目前而言,代码不会因未处理的异常而终止,因此表面上它似乎正在处理异常,但实际上块中的异常处理代码从未执行过。

问题

问题基本相同,但为了具体而重新措辞。

  1. CryptographicException由于ArgumentException封闭的 finally 块引发的异常而终止,因为删除该catch (CryptographicException)块会导致异常未处理并终止运行时,它是如何终止的?

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


额外信息 编辑

我仍在研究此问题的实际行为,并且许多答案对于至少回答上述问题的部分内容特别有帮助。

catch (CryptographicException)另一个奇怪的行为是 .NET 4.5 和 .NET 3.5 之间的差异,当您运行带有注释的代码块时会发生这种情况。.NET 4.5 将抛出CryptographicException并终止应用程序。但是,.NET 3.5 的行为似乎更符合异常所在的 C# 规范。

传播,我的孩子们
抛出 CryptographicExecption

未处理的异常:System.Security.Cryptography.CryptographicException [...]
ram.cs:第 23 行
抛出参数异常
捕获的参数异常
走出了异常雷区

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

4

3 回答 3

8

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

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

  • 一旦找到了 catch 块并且 CLR 知道从哪里恢复执行,阶段 2 就开始了。然后它可以可靠地确定需要执行哪些 finally 块。任何方法堆栈帧也会展开。

  • 一旦所有 finally 块都完成并且堆栈被展开到包含 catch 语句的方法,阶段 3 就开始了。指令指针设置为 catch 块中的第一条语句。如果此块不包含更多的 throw 语句,则在 catch 块之后的语句处正常执行。

因此,您的代码片段中的核心要求是范围内有一个 catch (CryptographicException)。没有它,阶段 1 将失败,CLR 不知道如何恢复执行。线程死了,通常也会根据异常处理策略终止程序。finally 块都不会执行。

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

于 2012-08-28T01:31:43.693 回答
6

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

基本上,执行时会发生什么:

  • CryptographicException最后被扔进inner。
  • 外部作用域最终执行,并抛出ArgumentException. 由于此时“CryptographicException”被“传播”,因此它丢失了。
  • 最终捕获发生,并被ArgumentException捕获。

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

根据您引用的 C# 语言规范,这正是发生的情况。第一个异常 ( CryptographicException) 有效地消失了——它“丢失了”。

但是,您只能通过显式使用 来达到此状态finally,因此我相信假设您在提供错误处理时考虑到了这种期望或可能性(正如您当时使用try的那样,这意味着您已经接受了您可能有例外)。

这基本上在规范中详细解释(您引用8.9.5的文本参考本节):8.10

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

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

于 2012-08-27T23:53:01.427 回答
2

事实证明,我并不疯狂。根据我对这个问题的回答,我认为我似乎很难理解规范中如此清楚地概述了什么。真的一点都不难掌握。

事实是规范是有道理的,而行为却不是。当您在较旧的运行时中运行代码时,这种情况更加明显,它的行为完全不同......或者至少看起来如此。

快速回顾

我在 x64 Win7 机器上看到的:

  • .NET v2.0-3.5 -CryptographicException抛出时的 WER 对话框。击中 后Close the program,程序继续运行,就好像从未抛出过 execption。应用程序未终止。这是阅读规范所期望的行为,并且由在 .NET 中实现异常处理的架构师明确定义。

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

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

它永远不是你所期望的

谁会怀疑即时调试器

您可能已经注意到,在 .NET 2 下运行应用程序会产生与 .NET 4 不同的错误对话框。但是,如果您像我一样,您会在开发周期中期待该窗口,因此您没有随便想想。

vsjitdebugger 可执行文件强制终止应用程序,而不是让它继续。在 2.0 运行时,dw20.exe并没有这种行为,其实你首先看到的就是那个 WER 消息。

由于 jit 调试器终止了应用程序,它使它看起来不符合规范所说的,而实际上它确实如此。

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

在 .NET 4.0 中运行


事实证明,有一种解决方法,尽管实际上没有理由解决这种行为,因为您的应用程序正在终止。

  1. 当即时调试器窗口弹出时,选中Manually choose the debugging engines并单击是,您要调试。
  2. 当 Visual Studio 为您提供引擎选项时,单击取消。
  3. 这将导致程序继续运行,或弹出 WER 对话框,具体取决于您的机器配置。如果发生这种情况,告诉它关闭程序并不会真正关闭它,它会继续运行,就好像一切正​​常。
于 2012-08-31T22:07:24.167 回答