为什么不抓住一般例外

Question

我的VS刚刚告诉我;

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

我为什么要那样做？如果我这样做,并没有捕获所有异常来处理它们,我的程序崩溃与所有流行的报告屏幕.我不希望我的用户得到这样的错误废话!

为什么我不能立刻捕获所有异常,向用户显示一个很好的警告说:"出了问题,不关心它,我会处理它,只是耐心等待"？

编辑:刚看到我在这里有一个骗局,对不起那个杜普

编辑2:澄清事情; 在捕获任何异常后我退出程序!我只是不希望我的用户看到"向microsoft报告"对话框,该对话框在控制台应用程序中引发未处理的异常时显示!

Answer 1

吞咽异常是一种危险的做法,因为:

• 它可以使用户在实际失败时思考某些事情.
• 它可以将您的应用程序置于您不计划的状态.
• 它使调试变得复杂,因为当你处理奇怪/破坏的行为而不是堆栈跟踪时,很难找到故障发生的位置.

你可以想象,其中一些结果可能是非常灾难性的,所以这样做是一个重要的习惯.

最佳实践

首先,防御性地编写代码,以便不会发生超出必要的异常.它们的计算成本很高.

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

对于意外的异常,您可以执行以下两项操作之一:

• 让它们正常冒泡并导致崩溃
• 赶上他们,优雅地失败

优雅地失败？

假设您正在ASP.Net中工作,并且您不希望向用户显示死亡的黄色屏幕,但您也不希望从开发团队隐藏问题.

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

这是我们的最后一道防线,如果我们最终收到一封电子邮件,我们会马上跳过它.

这种类型的模式是不一样的只是吞咽异常,在这里你有一个只存在于"假装"没有发生异常空catch块.

其他说明

在VS2010中,有一种称为intellitrace的东西,它允许您实际将应用程序状态通过电子邮件发送回家并逐步执行代码,检查异常时的变量值,等等.这将是非常有用的.

Answer 2

因为不加区别地(然后继续)吞下(捕获)异常的程序不能依赖于它们应该做的事情.这是因为你不知道什么样的例外被"忽略"了.如果存在溢出或内存访问错误导致从金融帐户中扣除错误金额会怎样？如果它将船驶入冰山而不是远离冰山怎么办？意外故障应始终导致应用程序终止.这迫使开发过程识别并纠正它发现的异常,(演示期间的崩溃是一个很好的激励因素),并且在生产中,允许适当设计的备份系统在软件遇到"意外"无法做到的时候做出反应旨在做.

编辑:澄清UI组件,服务或中间件组件之间的区别.

在服务或中间件组件中,没有用户在运行代码的同一进程空间内与代码组件进行交互,组件需要将异常"传递"到任何客户端组件,从而限制它当前正在处理的调用. .无论例外,它都应尽一切可能尝试这样做.但是,在发生意外或意外的异常的情况下,组件应该最终终止其运行的进程.对于预期或预期的异常,应该进行开发分析以确定是否,对于该特定异常,组件及其主机进程可以继续运行(处理将来的请求),或者是否应该终止它.

Answer 3

您应该处理您能够处理的确切异常,并让所有其他异常冒泡.如果它向用户显示消息,则表示您不太了解可以处理的内容.

Answer 4

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

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

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