为什么不捕获一般异常

我的VS刚刚告诉我；

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

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

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

Edit: 刚看到这里有一个骗子，抱歉Dupe

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

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

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

正如您可能想象的那样，其中一些结果可能是极其灾难性的，所以正确地做到这一点是一个重要的习惯。

最佳实践

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

精细地处理预期的异常（例如：FileNotFoundException） 如果可能。

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

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

优雅地失败？

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

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

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

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

其他注意事项

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