Question

Visual Studio曾经有一个特定的复选框“Break on Un-processed exception”。在2015年，这已被删除（或移动到我找不到的地方）。因此，如果我未能提供用户级异常处理程序，那么现在我的转换项目不再中断。我不想打破所有“抛出异常”，因为我处理特定的异常。就在我无法提供特定处理程序的地方。

现在我的代码只退出当前程序并继续在下一个调用堆栈位置执行，而不是好。

任何人都知道如何在Visual Studio 2015中获得此功能？我昨天刚升级到社区版。

Answer 1

默认情况下，在开始调试时，会出现一个名为“异常设置”的新窗口，该窗口显示在右下方窗格中。它具有您期望的所有选项。

你可以用 CTRL + ALT + E

提出来

这允许您挑选哪些异常导致调试器中断。

但关键是，您还可以设置这些异常是否总是中断，或者只有当它是未处理的异常时才会中断 - 但设置此异常并不是非常直观。

您需要先在工具＆gt;下查看“启用我的代码”。选项＆gt;调试。

然后，您可以在新的“例外设置”窗口中右键单击列标题（在抛出时中断），然后添加“其他操作”列，然后允许您将每个例外设置为“在用户未处理时继续”代码”。

因此，只需右键单击异常或整个组，然后禁用“在用户代码中未处理时继续”标志。不幸的是，“附加操作”列将显示为空，这与“在用户代码中未处理时中断”相同。

更多相关内容：

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Answer 2

我有同样的问题，我设法解决这个问题 -

按 Ctrl + Alt + e 调出 例外设置窗口。
勾选公共语言运行时例外。

就是这样！

由于我使用的是 x64版本的Windows ，我受到启发post。

Answer 3

对于想要仅在异常涉及其代码时破解的Google搜索者，Visual Studio 2015中有一个选项：选项 - ＆gt;调试 - ＆gt;常规 - ＆gt;只是我的代码。一旦检查，它就不会在代码之外管理（抛出和捕获）异常时中断。

Answer 4

微软巧妙地改变了新例外窗口中的逻辑。

请参阅http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

关键部分是：

重要说明


此新窗口包含与旧模式对话框相同的所有功能。调试器的任何功能都没有改变，只能改变它们的访问方式

当未处理异常时，调试器将始终中断

如果调试器在用户未处理的异常中断，则更改的设置已在上下文菜单
下移动
菜单位置已移至Debug - ＆gt; Windows - ＆gt;例外设置

然而，如果像我这样你的代码中有一个全局未处理异常处理程序那么该列表上的第二项是关键：对我来说，没有例外，因此真的没有处理，这似乎与VS2013不同。

为了回到VS打破未处理异常的行为，我必须勾选我想要打破的所有异常类型，然后确保＆＃34;其他选项＆＃34; （您可能需要使此列可见*）for＆＃34;在用户代码中未处理时继续＆＃34;是不设置。 VS2015逻辑不似乎认为我的全局未处理异常处理程序在用户代码＆＃34;中处理，因此它确实打破了这些;尽管如此，它并没有打破被捕获的异常。这使它像VS2013一样工作。

*如何启用＆＃34;附加操作＆＃34;柱

Answer 5

如果我在这里的行之间正确阅读，问题是你的异常实际上正在“消失”，即使默认的调试器行为应该在未处理的异常中中断。

如果您有异步方法，则可能遇到此问题，因为作为任务延续的一部分未在线程池线程上捕获的异常不被视为未处理的异常。相反，它们被吞下并与任务一起存储。

例如，看看这段代码：

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

如果使用默认调试器设置运行此程序（仅在未处理的异常上停止），则调试器不会中断。这是因为分配给continuation的线程池线程吞下了异常（将其传递给Task实例）并将自身释放回池中。

请注意，在这种情况下，真正的问题是永远不会检查Task返回的Test()。如果你的代码中存在类似类型的“即发即忘”逻辑，那么在抛出它们时你就不会看到异常（即使它们在方法中是“未处理的”）;只有当您通过等待任务观察任务，检查其结果或明确查看其异常时，才会显示该异常。

这只是猜测，但我认为你可能正在观察这样的事情。

Answer 6

根据我的经验，如果您更改任何内容，2015年的异常设置将完全失控。

预计如果你直到父母群体＆＃34; CLR＆＃34;那么你不应该得到任何未处理的破解行为。如果未处理异常，您将始终中断。但是，如果你没有取消CLR组，那么try ... catch中的代码应该不会导致中断。事实并非如此。

解决方案：在新的例外设置工具箱中，右键单击并选择＆＃34;恢复默认＆＃34;。 Taadaaaa ......它再次表现正常。现在不要搞砸它。

Answer 7

请按照说明操作：

在“例外设置”窗口中，右键单击窗口，然后选择“显示列”，打开上下文菜单。（如果您关闭了Just My Code，则不会看到此命令。）
您应该会看到名为“附加操作”的第二列。当用户代码未处理特定异常时，此列显示“继续”，这意味着如果在用户代码中未处理该异常但在外部代码中处理该异常，则调试器不会中断。
您可以针对特定异常更改此设置（选择例外，右键单击，选择/取消选择“在用户代码中未处理时继续”）或整个异常类别（例如，所有公共语言运行时异常））。

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

Answer 8

它有点令人困惑，而且在我看来不如旧的例外对话，但无论如何。

如果列表中有异常并勾选，那么只要抛出异常，调试器就会中断。

如果列表中没有取消或未取消异常，那么只有当用户未处理该异常类型时，调试器才会中断。

例如，在下面的屏幕截图中，只要抛出System.AccessViolationException，调试器就会中断，但是对于所有其他异常，只有在用户未处理异常时它才会中断。

Answer 9

当我升级到VS2015时，我也遇到了一些问题，其中异常用于“破坏”应用程序，但现在被忽略并直接传递。有时我们希望我们的代码故意在我们希望代码停止的地方抛出异常，而不是继续。我们总是使用短语Throw New Exception("Message")来让我们的代码有意破解：

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

使用VS2015时，经典的“System.Exception”就是我们说Throw New Exception时抛出的内容。因此，我们需要检查新的例外设置中的“System.Exception”标记：

Check the System.Exception Box

检查后，我们的代码按预期执行。

Answer 10

解决方案是在语义上与您认为的设置相反。您需要确保在用户代码未处理时继续 未启用，即未选中，如其他操作所示例外设置标签中的>列 - 见下文：

你实际上是说在代码中未处理时不会继续（即中断）

要做到这一点：

右键单击您关注的例外情况或一组例外情况（例如，通常是顶线＆＃39;公共语言运行时异常＆＃39;在树中）
选择在用户代码中未处理时继续（见下文）
确保例外未选中（见下文）
继续调试

那为我做了 - 再次开心。

这是在VS 2015

Answer 11

在Visual Studio中肯定存在一些错误，可能导致它被卡住而需要重启。甚至是VS2015。

我有一个单线程的情况，NullReferenceException被一个＆＃39;外部＆＃39;处理程序（仍然在我的代码中），即使我要求它在被提升时中断。

我意识到这是一个“处理过的”。例外，你正在谈论一个未经处理的＆＃39;一个 - 但我很确定有时快速重启VS会解决这个问题，如果IISRESET没有。

Answer 12

Visual Studio 2017可以很好地处理错误。另一方面，Visual Studio 2015会沉迷于任务的错误处理，因为在调试模式下，异步任务中发生的所有异常都会被捕获，但是如果我跳过它，则会无限期地挂起。如果在不调试的情况下执行，它将无限期挂起，不会捕获任何异常！我喜欢Visual Studio，自1995年以来一直使用它，而2015年是最差的版本，尽管我从2010年直接跳到2015年。我花了8个小时试图使这种异常处理无法成功。我在家用计算机上将确切的代码复制到2017年，并且运行良好。微软将任务推送到2015编译器无法正确处理的框架中，这让我非常恼火。

Visual Studio 2015打破未处理的异常无效

12 个答案: