在维护我同事的代码时，甚至有人声称自己是高级开发人员，我经常看到以下代码:
try
{
//do something
}
catch
{
//Do nothing
}
或者有时他们将日志信息写入日志文件，例如下面的try catch块
try
{
//do some work
}
catch(Exception exception)
{
WriteException2LogFile(exception);
}
我只是想知道他们所做的是不是最好的做法?这让我很困惑，因为在我看来，用户应该知道系统发生了什么。
当前回答
有时需要处理与用户无关的异常。
我的方法是:
在应用程序级别捕获未捕获的异常。在global.asax中)用于关键异常(应用程序可能没有用处)。这些例外情况我不太了解。只要在应用程序级别上登录它们，让系统完成它的工作。 捕捉“on place”并向用户显示一些有用的信息(输入错误的数字，无法解析)。 抓住位置，对边缘问题什么都不做，比如“我将在后台检查更新信息，但服务没有运行”。
它绝对不需要成为最佳实践。: -)
其他回答
没有任何参数的捕获只是简单地吃掉异常，没有任何用处。如果发生致命错误怎么办?如果不带参数地使用catch，就无法知道发生了什么。
catch语句应该捕获更具体的异常，如FileNotFoundException，然后在最后捕获Exception，它将捕获任何其他异常并记录它们。
To me, handling exception can be seen as business rule. Obviously, the first approach is unacceptable. The second one is better one and it might be 100% correct way IF the context says so. Now, for example, you are developing an Outlook Addin. If you addin throws unhandled exception, the outlook user might now know it since the outlook will not destroy itself because of one plugin failed. And you have hard time to figure out what went wrong. Therefore, the second approach in this case, to me, it is a correct one. Beside logging the exception, you might decide to display error message to user - i consider it as a business rule.
更好的方法是第二种(指定异常类型的方法)。这样做的好处是，您知道这种类型的异常可以发生在您的代码中。您正在处理这种类型的异常，您可以继续。如果出现任何其他异常，那么这意味着有错误，这将帮助您找到代码中的错误。应用程序最终会崩溃，但你会知道你错过了什么(bug)，需要修复。
留下空白的catch块是最糟糕的做法。如果出现错误，最好的处理方法是:
登录到文件数据库等。 尝试在飞行中修复它(可能尝试做该操作的替代方式) 如果我们不能修复这个问题，那么就通知用户有错误，当然还要中止操作
最佳实践是在错误发生时抛出异常。因为发生了一个错误，它不应该被隐藏。
但在现实生活中，你可以有几种情况想要隐藏它
您依赖于第三方组件，并且希望在出现错误时继续执行程序。 您有一个业务案例，需要继续进行，以防出现错误
