为什么不捕捉一般异常 [英] Why not catch general Exceptions

问题描述

警告2 CA1031：Microsoft.Design：修改'Program.Main（string []）'要捕获比异常更具体的异常，或者重新启动异常。

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

为什么我不能一次捕获所有异常，向用户显示一个很好的警告：Something出错了，不在乎，我会处理它，只要耐心等待？

修改：刚看到我有一个欺骗在这里，对于 Dupe

Edit2 ：澄清事情;任何异常被捕获后，我都退出程序！我只是不希望我的用户在控制台应用程序中出现未处理的异常时显示报告给微软对话框！

解决方案

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

• 它可能导致用户在实际失败时考虑成功。


• 它可以将您的应用程序置于您没有计划的状态。


• 它使调试变得复杂，因为当处理奇怪/破坏的行为而不是堆栈跟踪时，很难找出故障发生的地方。

你可以想象，其中一些结果可能会非常灾难性，所以这样做是一个重要的兔子。

最佳实践

首先，代码防御，以便异常不会发生必要。它们在计算上是昂贵的。

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

对于意外的例外情况，您可以执行以下两项操作之一：

• 让他们正常起泡并导致崩溃


• 抓住他们并正常失败

正常失败

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

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

这是我们的最后一道防线，如果我们最终得到我们立即跳上电子邮件。

这种类型的模式不是与只是吞下异常相同，你有一个空的Catch块只存在于假装没有发生例外。

其他注释

在VS2010中，有一些名为intellitrace的东西将允许您实际上将应用程序状态发送回家并逐步执行代码，检查异常时的变量值等等。这将非常有用。

My VS just told me;

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

Why should I do that? If I do so, and don't catch all exceptions to handle them, my program crashes with the all-popular report-screen. I don't want my users to get such error-crap!

Why should I not catch all exceptions at once to display a nice warning to the user saying: "Something went wrong, don't care about it, I will handle it, just be patient"?

Edit: Just saw I have a dupe here, sorry for that Dupe

Edit2: To clarify things; I do exit the program after any exception has been catched! I just don't want my user to see that "report to microsoft" dialog that show up when an unhandled exception is raised in a console-application!

解决方案

Swallowing exceptions is a dangerous practice because:

• It can cause the user to think something succeeded when it actually failed.
• It can put your application into states that you didn't plan for.
• It complicates debugging, since it's much harder to find out where the failure happened when you're dealing with bizarre/broken behavior instead of a stack trace.

As you can probably imagine, some of these outcomes can be extremely catastrophic, so doing this right is an important habbit.

Best Practice

First off, code defensively so that exceptions don't occur any more than necessary. They're computationally expensive.

Handle the expected exceptions at a granular level (for example: FileNotFoundException) when possible.

For unexpected exceptions, you can do one of two things:

• Let them bubble up normally and cause a crash
• Catch them and fail gracefully

Fail Gracefully?

Let's say you're working in ASP.Net and you don't want to show the yellow screen of death to your users, but you also don't want problems to be hidden from the dev team.

In our applications, we usually catch unhandled exceptions in global.asax and then do logging and send out notification emails. We also show a more friendly error page, which can be configured in web.config using the customErrors tag.

That's our last line of defense, and if we end up getting an email we jump on it right away.

That type of pattern is not the same as just swallowing exceptions, where you have an empty Catch block that only exists to "pretend" that the exception did not occur.

Other Notes

In VS2010, there's something called intellitrace coming that will allow you to actually email the application state back home and step through code, examine variable values at the time of the exception, and so on. That's going to be extremely useful.

这篇关于为什么不捕捉一般异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！