exception - 为什么不捕获一般异常

Question

我的 VS 刚刚告诉我；

Warning 2 CA1031 : Microsoft.Design : Modify 'Program.Main(string[])' to catch a more specific exception than 'Exception' or rethrow the exception.

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

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

编辑:刚刚看到我这里有一个骗子，抱歉Dupe

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

Answer 1

吞没异常是一种危险的做法，因为:

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

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

最佳实践

首先，进行防御性编码，以便不会发生不必要的异常。它们的计算成本很高。

尽可能在粒度级别处理预期的异常(例如:FileNotFoundException)。

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

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

优雅地失败？

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

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

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

这种类型的模式与吞咽异常不同，在吞咽异常中，您有一个空的 Catch block ，它的存在只是为了“假装”异常没有发生。

其他说明

在 VS2010 中，出现了一种称为 intellitrace 的功能，它允许您通过电子邮件将应用程序状态实际发送回家并单步执行代码、检查异常时的变量值，等等。这将非常有用。