更好的方法是第二种(指定异常类型的方法)。这样做的好处是，您知道这种类型的异常可以发生在您的代码中。您正在处理这种类型的异常，您可以继续。如果出现任何其他异常，那么这意味着有错误，这将帮助您找到代码中的错误。应用程序最终会崩溃，但你会知道你错过了什么(bug)，需要修复。

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.

对于异常，我尝试如下:

首先，我捕获特殊类型的异常，如除零、IO操作等，并根据这些编写代码。例如，除以0，这取决于我可以提醒用户的值的出处(例如，一个简单的计算器在中间计算(而不是参数)中到达一个除以0)，或者静默地处理这个异常，记录它并继续处理。

然后我尝试捕获剩余的异常并记录它们。如果可能，允许执行代码，否则提醒用户发生错误，并要求他们发送错误报告。

在代码中，是这样的:

try{
    //Some code here
}
catch(DivideByZeroException dz){
    AlerUserDivideByZerohappened();
}
catch(Exception e){
    treatGeneralException(e);
}
finally{
    //if a IO operation here i close the hanging handlers for example
}

最佳实践是在错误发生时抛出异常。因为发生了一个错误，它不应该被隐藏。

但在现实生活中，你可以有几种情况想要隐藏它

您依赖于第三方组件，并且希望在出现错误时继续执行程序。 您有一个业务案例，需要继续进行，以防出现错误

最佳实践是异常处理永远不应该隐藏问题。这意味着try-catch块应该非常少。

在三种情况下使用try-catch是有意义的。

Always deal with known exceptions as low-down as you can. However, if you're expecting an exception it's usually better practice to test for it first. For instance parse, formatting and arithmetic exceptions are nearly always better handled by logic checks first, rather than a specific try-catch. If you need to do something on an exception (for instance logging or roll back a transaction) then re-throw the exception. Always deal with unknown exceptions as high-up as you can - the only code that should consume an exception and not re-throw it should be the UI or public API.

假设你连接到一个远程API，在这里你知道预期某些错误(在这些情况下有一些事情)，所以这是情况1:

try 
{
    remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex) 
{
    // User's security details have expired
    return false;
}

return true;

注意，没有捕获其他异常，因为它们不是预期的。

现在假设您试图将一些东西保存到数据库中。如果失败，我们必须回滚它，所以我们有情况2:

try
{
    DBConnection.Save();
}
catch
{
    // Roll back the DB changes so they aren't corrupted on ANY exception
    DBConnection.Rollback();

    // Re-throw the exception, it's critical that the user knows that it failed to save
    throw;
}

注意，我们重新抛出了异常——更高级别的代码仍然需要知道某些事情失败了。

最后我们有了UI——这里我们不想有完全未处理的异常，但我们也不想隐藏它们。这里是情况3的例子:

try
{
    // Do something
}
catch(Exception ex) 
{
    // Log exception for developers
    WriteException2LogFile(ex);

    // Display message to users
    DisplayWarningBox("An error has occurred, please contact support!");
}

然而，大多数API或UI框架都有处理情形3的通用方法。例如ASP。Net有一个黄色的错误屏幕，用来转储异常详细信息，但是在生产环境中可以用更通用的消息代替。遵循这些是最佳实践，因为它节省了大量代码，但也因为错误记录和显示应该是配置决策，而不是硬编码。

这意味着情况1(已知异常)和情况3(一次性UI处理)都有更好的模式(避免预期错误或将错误处理交给UI)。

即使情况2也可以被更好的模式所取代，例如事务作用域(使用块回滚在块期间未提交的任何事务)使开发人员更难获得错误的最佳实践模式。

例如，假设你有一个大规模的ASP。网络应用程序。错误日志可以通过ELMAH进行记录，错误显示可以是本地的信息YSoD和生产中的漂亮的本地化消息。数据库连接都可以通过事务作用域并使用块。您不需要单个的try-catch块。

TL;DR:最佳实践实际上是根本不使用try-catch块。

我可以告诉你:

代码片段#1是不可接受的，因为它忽略了异常。(它像什么都没发生一样吞下去)。

所以不要添加不做任何事情或只是重新抛出的catch块。

Catch块应该增加一些价值。例如，向最终用户输出消息或记录错误。

不要对正常的流程序逻辑使用异常。例如:

例如输入验证。<-这不是有效的例外情况，而是你应该写方法IsValid(myInput);检查输入项是否有效。

设计代码以避免异常。例如:

int Parse(string input);

如果我们传递一个不能解析为int的值，这个方法会抛出一个异常，我们可以这样写:

bool TryParse(字符串输入，输出int结果);<-该方法将返回布尔值，表示解析是否成功。

也许这有点超出了这个问题的范围，但我希望这将帮助您在涉及try {} catch(){}和异常时做出正确的决定。