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

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

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

留下空白的catch块是最糟糕的做法。如果出现错误，最好的处理方法是:

登录到文件数据库等。 尝试在飞行中修复它(可能尝试做该操作的替代方式) 如果我们不能修复这个问题，那么就通知用户有错误，当然还要中止操作

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

你唯一应该让用户担心代码中发生的事情的时候是他们是否可以或需要做一些事情来避免这个问题。如果他们可以更改表单上的数据、按下按钮或更改应用程序设置以避免这个问题，请让他们知道。但是用户无法避免的警告或错误只会让他们对你的产品失去信心。

异常和日志是为您，即开发人员，而不是最终用户准备的。当您捕捉到每个异常时，了解正确的做法要比仅仅应用一些黄金规则或依赖于应用程序范围的安全网要好得多。

盲目的编码是唯一一种错误的编码。事实上，您觉得在这些情况下可以做一些更好的事情，这表明您对良好的编码进行了投资，但避免试图在这些情况下确定一些通用规则，并首先了解抛出某些东西的原因，以及您可以做些什么来从中恢复。

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

我的异常处理策略是:

通过连接到应用程序来捕获所有未处理的异常。线程异常事件，然后决定: 对于UI应用程序:向用户弹出一个道歉消息(WinForms) 对于服务或控制台应用程序:将其记录到文件(服务或控制台)

然后我总是在try/catch中附上外部运行的每一段代码:

WinForms基础架构触发的所有事件(加载、单击、选定更改…) 由第三方组件触发的所有事件

然后加上try/catch

我所知道的所有操作可能并不总是有效(IO操作，潜在的零除法计算……)。在这种情况下，我抛出一个新的ApplicationException(“自定义消息”，innerException)来跟踪实际发生的事情

此外，我尽最大努力对异常进行正确排序。但也有例外:

需要立即显示给用户 当它们发生时，需要一些额外的处理来将它们放在一起，以避免级联问题(例如:在TreeView填充期间将. endenddate放在finally部分) 用户并不关心，但重要的是要知道发生了什么。所以我总是记录它们: 在事件日志中 或者在磁盘上的.log文件中

在应用程序顶级错误处理程序中设计一些静态方法来处理异常是一个很好的实践。

我还强迫自己试着:

记住，所有的异常都被冒泡到顶层。没有必要把异常处理程序放在任何地方。 可重用的或深度调用的函数不需要显示或记录异常:它们要么自动生成，要么在异常处理程序中使用一些自定义消息重新抛出。

最后:

Bad:

// DON'T DO THIS; ITS BAD
try
{
    ...
}
catch 
{
   // only air...
}

用处:

// DON'T DO THIS; IT'S USELESS
try
{
    ...
}
catch(Exception ex)
{
    throw ex;
}

have a try finally without a catch是完全正确的:

try
{
    listView1.BeginUpdate();

    // If an exception occurs in the following code, then the finally will be executed
    // and the exception will be thrown
    ...
}
finally
{
    // I WANT THIS CODE TO RUN EVENTUALLY REGARDLESS AN EXCEPTION OCCURRED OR NOT
    listView1.EndUpdate();
}

我在顶层做的是:

// i.e When the user clicks on a button
try
{
    ...
}
catch(Exception ex)
{
    ex.Log(); // Log exception

    -- OR --
    
    ex.Log().Display(); // Log exception, then show it to the user with apologies...
}

我在一些被调用的函数中所做的:

// Calculation module
try
{
    ...
}
catch(Exception ex)
{
    // Add useful information to the exception
    throw new ApplicationException("Something wrong happened in the calculation module:", ex);
}

// IO module
try
{
    ...
}
catch(Exception ex)
{
    throw new ApplicationException(string.Format("I cannot write the file {0} to {1}", fileName, directoryName), ex);
}

异常处理(自定义异常)有很多事情要做，但我试图记住的那些规则对于我做的简单应用程序已经足够了。

下面是一个扩展方法的例子，它以一种舒适的方式处理捕获的异常。它们以一种可以链接在一起的方式实现，并且非常容易添加您自己捕获的异常处理。

// Usage:

try
{
    // boom
}
catch(Exception ex)
{
    // Only log exception
    ex.Log();

    -- OR --

    // Only display exception
    ex.Display();

    -- OR --

    // Log, then display exception
    ex.Log().Display();

    -- OR --

    // Add some user-friendly message to an exception
    new ApplicationException("Unable to calculate !", ex).Log().Display();
}

// Extension methods

internal static Exception Log(this Exception ex)
{
    File.AppendAllText("CaughtExceptions" + DateTime.Now.ToString("yyyy-MM-dd") + ".log", DateTime.Now.ToString("HH:mm:ss") + ": " + ex.Message + "\n" + ex.ToString() + "\n");
    return ex;
}

internal static Exception Display(this Exception ex, string msg = null, MessageBoxImage img = MessageBoxImage.Error)
{
    MessageBox.Show(msg ?? ex.Message, "", MessageBoxButton.OK, img);
    return ex;
}