您应该考虑这些异常的设计指南

异常抛出 使用标准异常类型 异常和性能

https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

第二种方法很好。

如果你不想显示错误，并通过显示运行时异常(即。错误)，这与他们无关，然后只记录错误，技术团队可以寻找问题并解决它。

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

我建议您对整个应用程序采用第二种方法。

我知道这是一个老问题，但这里没有人提到MSDN的文章，实际上是文档为我澄清了这个问题，MSDN在这方面有一个非常好的文档，当以下条件为真时，你应该捕获异常:

您已经很好地理解了异常可能被抛出的原因，并且可以实现特定的恢复，例如在捕获FileNotFoundException对象时提示用户输入一个新的文件名。 您可以创建并抛出一个新的、更具体的异常。

int GetInt(int[] array, int index)
{
    try
    {
        return array[index];
    }
    catch(System.IndexOutOfRangeException e)
    {
        throw new System.ArgumentOutOfRangeException(
            "Parameter index is out of range.");
    }
}

您希望在将异常传递给其他处理之前对其进行部分处理。在下面的示例中，catch块用于在重新抛出异常之前向错误日志添加条目。

    try
{
    // Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
    // Call a custom error logging procedure.
    LogError(e);
    // Re-throw the error.
    throw;     
}

我建议阅读整个“异常和异常处理”部分以及异常的最佳实践。

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

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

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

最佳实践是异常处理永远不应该隐藏问题。这意味着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块。

没有任何参数的捕获只是简单地吃掉异常，没有任何用处。如果发生致命错误怎么办?如果不带参数地使用catch，就无法知道发生了什么。

catch语句应该捕获更具体的异常，如FileNotFoundException，然后在最后捕获Exception，它将捕获任何其他异常并记录它们。