Visual Studio 2019 中断已处理的异常 (C#)答案

【问题标题】：Visual Studio 2019 breaks on already handled exception (C#)Visual Studio 2019 中断已处理的异常 (C#)
【发布时间】：2020-05-20 07:07:41
【问题描述】：

我在 try-catch 块中有一些代码，可能会引发异常。

异常在 catch 块中处理。

代码在 VS 2017 下工作。但是，切换到 VS2019，调试器将无法继续（见截图）

我如何告诉调试器不要在已经处理的异常处中断？

[编辑]

在这种特殊情况下，可以通过更仔细的代码轻松避免异常，或者通过取消选中“抛出此异常类型时中断”来禁用异常。。 p>

但这不是我的问题。

我的问题是：

为什么 VS 2019 在处理异常时会中断？

我怎样才能告诉它不这样做？

【问题讨论】：

写评论而不是留下不喜欢，会更感激
只要去掉“抛出异常类型时中断”。或者在异常设置中禁用“NullReferenceException”。但是，我不建议这样做。您永远不应该捕获此类一般异常，您应该更好地处理 NULL 检查。
感谢您的评论。然而，这不是我要问的。我想知道为什么 VS 2019 决定在未处理的异常时中断，我怎么能告诉它不要这样做。

标签： c# exception visual-studio-2019

【解决方案1】：

[编辑：这个问题不是关于正确处理，而是关于破坏行为。包含的例子当然是不推荐处理]

根据 Mattias Larsson 的回答，默认情况下，许多异常总是会中断执行，无论它们是否被处理。 System.NullReferenceException 就是其中之一。为防止这种情况，您可以取消选中框 break when this exception type is thrown。这样做会导致以下行为：

正如您之前评论的，当未处理时，您希望调试器继续在 System.NullReferenceException 上中断；这是标准行为，因为这种异常很关键，即不可恢复（也许有更好的术语？）。

【讨论】：

您想停止在整个应用程序中出现任何类型的空引用异常吗？如果你问我，那就是错误的秘诀。
这也是和stackoverflow.com/a/61907337/4122889一样的答案，并且没有添加新信息
我投了反对票，因为答案 a) 应该包括“选中那个框”的含义——这意味着所有异常都被忽略，这可能是“危险的”，就像非常烦人一样，并且 b) 因为它确实不要添加我没有阅读或可以从其他答案中收集到的任何新信息 - 这是所有新答案的要求（它们包含新信息）。另外 - 不要把这个看得太个人化 - 我投了反对票，并花时间包括我对你（而不是我自己）的批评，所以告诉我“阅读”是我认为我不应该得到的敌意。让我们保持友好:)
@GeorgeKerwood 感谢您花时间分析我的问题。但是，相同的代码在 VS 2017 中不会抛出任何异常。我想它是 VS 2019 中的一个新“功能”
@sommmen，请原谅我的沮丧，继续你的观点 a) 我在这里澄清你的确切担忧。取消选中该框将不会“在任何类型的空引用异常处停止中断”，如图所示，它只会在该类型的未处理异常上停止中断。尽管未选中该框，但看看它是如何在第 25 行中断的？随意自己测试一下。 b) 增加的是关于 a) 点的清晰性。我想演示一下复选框的作用。

【解决方案2】：

有许多例外情况（默认情况下）会中断执行，即使您有“全部捕获”也是如此。 System.NullReferenceException 就是其中之一。

但是，正如您在屏幕截图的弹出窗口中看到的那样，您可以选择“关闭”此特定异常。当前选中：“抛出此异常类型时中断”。

取消选中此框，然后重试！

（您可以在此菜单选项中进一步调整异常设置：Debug / Windows / Exception Settings。）

【讨论】：

我可以看到这个选项。但是我确实希望 VS 在这种类型的异常中中断，只要它未处理
据我所知，如果你没有捕捉到异常，即使你没有选中这个框，调试器也应该停止。
在异常设置中似乎只有异常类型。我找不到类似“中断处理异常”的内容
@MattiasLarsson 你的意思是我应该明确地捕获“System.NullReferenceException”，而不是一般的“Exception”吗？（与 VS2017 中相同的代码仍然有效）
@DSB，我建议您不要依赖 try-catch 来处理像 null 异常这样基本的事情。也许您的方法可以使用标准条件逻辑评估空参数？

【解决方案3】：

关于为什么这是“不好的做法”，已经有很多说法了。

话虽如此，有debuggerStepThrough

https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debuggerstepthroughattribute?view=netcore-3.1

请务必阅读文档以了解其中的含义 - 例如。您需要启用 JMC。

在进行这些肮脏的异常检查时，请尽可能具体，以避免意外；

try
{
   var x = MyFunc();

   // We do a check here that will throw an exception 
   var y = ThisFuncWillThrowNullRef(x);
}
catch(exception)
{
    // ALL exceptions are swallowed
    // What if MyFunc() throws an exception instead of the second function? what do we do then?
}

编辑；在我工作的应用程序中，即使我们像您现在所做的那样“吞下”异常，我们也会明确而详细地记录异常。总是。异常比不知道发生了什么更容易解决，并且随着您的应用程序变得越来越大，引擎盖下发生的事情会越来越多。

【讨论】：

OP 解释说这不是关于正确异常处理的问题，而是 VS 中断的行为。
问题被明确表述为：“为什么 VS 2019 会在已处理的异常处中断？我怎么能告诉它不这样做？”这个答案没有提到任何一点。