为什么不捕获一般异常

Question

我的 VS 刚刚告诉我；

警告 2 CA1031：Microsoft.Design：修改“Program.Main(string[])”以捕获比“Exception”更具体的异常或重新抛出异常。

我为什么要这样做？ 如果我这样做，并且没有捕获所有异常来处理它们，我的程序就会崩溃并显示所有流行的报告屏幕。 我不希望我的用户遇到这样的错误！

为什么我不应该一次捕获所有异常以向用户显示一个很好的警告说：“出了点问题，别管它，我会处理它，耐心等待”？

编辑：刚刚看到我在这里有一个骗子，对不起那个骗子

Edit2 ：澄清事情； 在捕获到任何异常后，我确实退出了程序！ 我只是不希望我的用户看到在控制台应用程序中引发未处理的异常时出现的“向微软报告”对话框！

Answer 1

吞下异常是一种危险的做法，因为：

• 它可能会导致用户在实际失败时认为某事成功了。
• 它可以将您的应用程序置于您没有计划的状态。
• 它使调试变得复杂，因为当您处理奇怪/损坏的行为而不是堆栈跟踪时，要找出故障发生的位置要困难得多。

正如您可能想象的那样，其中一些结果可能是极其灾难性的，因此正确地执行此操作是一个重要的习惯。

最佳实践

首先，进行防御性编码，以便在必要时不会发生异常。 它们在计算上很昂贵。

尽可能在粒度级别处理预期的异常（例如： FileNotFoundException ）。

对于意外异常，您可以执行以下两种操作之一：

• 让它们正常冒泡并导致崩溃
• 抓住他们并优雅地失败

优雅地失败？

假设您在 ASP.Net 中工作，并且不想向用户显示死亡黄屏，但也不希望开发团队发现问题。

在我们的应用程序中，我们通常会在global.asax捕获未处理的异常，然后进行日志记录并发送通知电子邮件。 我们还展示了一个更友好的错误页面，可以在web.config使用customErrors标签进行配置。

这是我们的最后一道防线，如果我们最终收到一封电子邮件，我们会立即采取行动。

这种类型的模式是不一样的只是吞咽例外，那就是你有一个空的catch块只存在于“假装”没有发生异常。

其他注意事项

在 VS2010 中，有一种叫做 Intellitrace 的东西即将到来，它允许您将应用程序状态通过电子邮件实际发送回家并逐步执行代码，检查异常时的变量值，等等。 这将非常有用。

Answer 2

因为不分青红皂白地吞下（捕获）异常（然后继续）的程序不能被依赖来做它们应该做的事情。 这是因为您不知道“忽略”了什么样的异常。 如果发生溢出或内存访问错误导致从金融账户中扣除错误金额怎么办？ 如果它将船驶入冰山而不是远离它会怎样？ 意外故障应始终导致应用程序终止。 这会迫使开发过程识别并纠正它发现的异常（演示期间的崩溃是一个很好的动力），并且在生产中，允许适当设计的备份系统在软件遇到“意外”无法执行其操作时做出反应旨在做。

编辑：澄清 UI 组件与服务或中间件组件之间的区别。

在服务或中间件组件中，没有用户在运行代码的同一进程空间内与代码组件交互，该组件需要将异常“传递”给任何客户端组件发起它当前正在处理的调用. 不管有什么例外，它都应该尽一切可能来做到这一点。 然而，情况仍然如此，如果发生意外或意外异常，组件最终应终止其正在运行的进程。对于预期或预期异常，应进行发展分析以确定是否，对于该特定异常，组件及其宿主进程可以继续运行（处理未来的请求），或者是否应该终止。

Answer 3

您应该处理您能够处理的确切异常，并让所有其他异常冒泡。 如果它向用户显示一条消息，则表示您不太清楚自己可以处理什么。

Answer 4

在研究过紧急救援人员使用的设备后，我宁愿用户看到丑陋的错误消息，也不愿意外吞下一个异常，从而误导用户相信一切“正常”。 根据您的应用程序，后果可能是从一无所有到销售损失到灾难性的生命损失。

如果一个人要捕获所有异常，显示一个更好的错误对话框，然后退出应用程序，那没关系..但是如果他们在吞下一个未知异常后继续运行，我会为此解雇一个人。 不行。 曾经。

好的编码是关于假设人类会犯错误的实践。 假设所有“关键”异常都已被捕获和处理是一个坏主意。

Answer 5

简单的答案：你应该修复你的错误。 找到引发异常的地方，除非它超出您的控制范围 - 修复它。 捕获（不重新抛出）各种异常也违反了异常中立性。 通常，您不想这样做（尽管在main中捕获异常看起来像特殊情况）

Answer 6

由于您的警告信息显示，这是在main（），我假设在较低水平，你只捕获更具体的异常。

对于 Main()，我会考虑两种情况：

1. 您自己的（调试）构建，您希望在其中获得所有异常信息：不要在此处捕获任何异常，因此调试器会中断并且您拥有调用堆栈，
2. 您的公开发布，您希望应用程序在其中正常运行：Catch Exception 并显示一条不错的消息。 这总是比“发送报告”窗口更好（对于普通用户）。

要很好地做到这一点，只需检查是否定义了 DEBUG（并定义它，如果 VS 没有自动执行此操作）：

#if DEBUG
  yadda(); // Check only specific Exception types here
#else
  try
  {
    yadda();
  }
  catch (Exception e)
  {
     ShowMessage(e); // Show friendly message to user
  }
#endif

我会禁用关于捕获一般异常的警告，但仅对于您的 Main() 函数，在任何其他方法中捕获 Exception 都是不明智的，正如其他海报已经说过的那样。

Answer 7

有一种方法可以抑制来自代码分析的某些消息。 我出于这个确切原因使用了它（为了记录目的而捕获一般异常）并且它非常方便。 当您添加此属性时，它表明您至少承认您因特定原因违反了规则。 对于不正确的 catch 块，您仍然会收到警告（为了记录以外的目的而捕获一般异常）。

MSDN SuppressMessageAttribute

Answer 8

这里所有的答案都很好。 但我想再提一个选择。

作者意图显示一些花哨的信息是可以理解的。 此外，默认的 Windows 错误消息非常难看。 此外，如果应用程序未提交到“Windows Excellence Program”，开发人员将不会收到有关此问题的信息。 那么如果没有帮助，使用默认运行时处理程序有什么意义呢？

这里的事情是 CLR 主机的默认异常处理程序 ( https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/9x0wh2z3(v=vs.90)?redirectedfrom=MSDN ) 以非常安全的方式工作。 其目的很明确：记录错误，将其发送给开发人员，设置进程的返回码并终止它。 如何更改它的一般方法是编写自己的主机。 在这种情况下，您可以提供自己的异常处理方式。

不过，有一个简单的解决方案可以满足 CA1031 并且仍然满足您的大部分需求。

捕获异常时，您可以用自己的方式处理它（记录、显示消息等），最后您可以设置进程结果代码并退出（使用 Thread.Abort 和“Exit”方法的组合，对于例）。 不过，在 catch 块的末尾，您可以只输入“throw;”。 （由于 ThreadAbortedException 将永远不会被调用，但会满足规则）。 仍然有一些情况，如 StackOverflowException，不能像这样处理，您将看到默认消息框，用于修复您需要回退到自定义 CLR 主机选项的问题。

此外，仅供参考，您的应用程序可以运行多个线程（除了执行 Main 方法的线程）。 要接收所有异常，您可以使用 AppDomain.UnhandledException。 此事件不允许您将异常“标记”为已处理，您仍然可以使用 Thread.Join() 冻结线程，然后使用另一个（另外一个）线程完成工作（日志、msgbox、退出）。

我明白这一切看起来有点棘手，可能不正确，但我们必须处理 AppDomain.UnhandledException、ThreadAbortException、CorruptedState 异常和默认 CLR 主机的实现。 所有这些最终都没有给我们留下太多选择。

Answer 9

当您捕获一般异常时，您会得到潜在的对用户隐藏运行时问题的副作用，这反过来会使调试复杂化。 此外，通过捕获一般异常，您忽略了一个问题（您可能会在其他地方抛出）。

Answer 10

您可以设置 try catch 以捕获多种不同的行为类型并根据类型处理异常。 对于框架中的大多数方法和属性，您还可以查看它们能够抛出哪些异常。 因此，除非您从极小的代码块中捕获异常，否则您应该捕获特定的异常。

Answer 11

在 VS 中，您可以设置一个自定义错误页面以在出现问题时向用户显示，而不是在 try-catch 中捕获它。 我假设因为您使用的是 VS，所以您使用的是 ASP .NET。 如果是这样，请将此标签添加到 System.Web 标签下的 Web.Config 中：

<customErrors mode="RemoteOnly" defaultRedirect="~/CustomErrorPage.aspx" redirectMode="ResponseRewrite" />

您还可以在 Global.asax 文件中捕获所有未捕获的异常（如果您还没有它：右键单击 web 项目，选择添加项目，然后搜索它）。 该文件中有一堆应用程序范围的事件处理程序，例如“Application_Error”，它们捕获应用程序中未捕获的每个异常，因此您不必一直使用 Try-Catch。 如果发生异常，这可以很好地用于向自己发送电子邮件，并且如果您不想使用上面的 customErrors 标记，则可能会将它们重定向到您的主页或其他内容。

但最终您不想将整个应用程序包装在 try-catch 中，也不想捕获一般异常。 Try-catch 通常会减慢您的应用程序的速度，并且很多时候如果您捕获每个一般异常，那么您可能直到几个月或几年后才知道存在错误，因为 try-catch 导致您忽略了它。

Answer 12

我完全是为了捕获特定的已知异常和处理状态……但我使用通用捕获异常来快速定位问题并将错误传递给调用处理状态的方法就好了。 在开发过程中，当这些被捕获时，它们在一般异常旁边有一个位置，并在发布时处理一次。

我相信一旦代码投入生产，人们应该尝试删除这些，但在最初的代码创建过程中不断被唠叨有点太多了。

因此，通过在Microsoft.CodeQuality.Analyzers找到的项目设置关闭（取消选中）警告。 这是在Code Analysis下的项目设置中找到的：