如何使用 try catch 进行异常处理是最佳实践

我的异常处理策略是：

要通过挂钩 Application.ThreadException 事件来捕获所有未处理的异常，然后决定： 对于 UI 应用程序：使用道歉消息 (WinForms) 将其弹出给用户 对于服务或控制台应用程序：将其记录到文件（服务或控制台）

对于 UI 应用程序：通过道歉消息将其弹出给用户（WinForms）

对于服务或控制台应用程序：将其记录到文件（服务或控制台）

然后，我总是将 在外部运行的每一段代码 包含在 try/catch 中：

WinForms 基础结构触发的所有事件（Load、Click、SelectedChanged...）

第三方组件触发的所有事件

然后我附在“尝试/捕获”中

我所知道的所有操作可能不会一直有效（IO 操作、具有潜在零除法的计算……）。在这种情况下，我抛出一个新的 ApplicationException("custom message", innerException) 来跟踪实际发生的情况

此外，我尽我所能正确地对异常进行排序。有以下例外情况：

需要立即显示给用户

当它们发生时需要一些额外的处理来将它们放在一起以避免级联问题（即：在 TreeView 填充期间将 .EndUpdate 放在 finally 部分中）

用户不在乎，但重要的是要知道发生了什么。所以我总是记录它们：

在事件日志中

或在磁盘上的 .log 文件中

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

我也强迫自己尝试：

请记住，所有异常都会冒泡到顶层。没有必要将异常处理程序放在任何地方。

可重用或深度调用的函数不需要显示或记录异常：它们要么自动冒泡，要么在我的异常处理程序中使用一些自定义消息重新抛出。

所以最后：

坏的：

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

无用：

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

最后尝试没有捕获是完全有效的：

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;
}

---

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

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

始终尽可能低调地处理已知异常。但是，如果您预计会出现异常，通常最好先对其进行测试。例如，解析、格式化和算术异常几乎总是首先通过逻辑检查来更好地处理，而不是特定的 try-catch。如果您需要对异常执行某些操作（例如记录或回滚事务），则重新抛出异常。始终尽可能高地处理未知异常——唯一应该使用异常而不重新抛出异常的代码应该是 UI 或公共 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 也可以用更好的模式代替，例如 transaction scopes（using 块回滚在块期间未提交的任何事务）使开发人员更难将最佳实践模式弄错。

例如，假设您有一个大型 ASP.Net 应用程序。错误记录可以通过 ELMAH 进行，错误显示可以是本地的 YSoD 信息，也可以是生产中很好的本地化消息。数据库连接都可以通过事务范围和 using 块。您不需要单个 try-catch 块。

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

---

异常是阻塞错误。

首先，最佳实践应该是不要为任何类型的错误抛出异常，除非它是阻塞错误。

如果错误是阻塞的，则抛出异常。一旦异常已经抛出，就不需要隐藏它，因为它是异常的；让用户知道它（你应该在 UI 中将整个异常重新格式化为对用户有用的东西）。

作为软件开发人员，您的工作是努力防止某些参数或运行时情况可能以异常结束的异常情况。也就是说，不能忽略异常，但必须避免这些异常。

例如，如果您知道某些 integer 输入可能带有无效格式，请使用 int.TryParse 而不是 int.Parse。在很多情况下，您可以这样做，而不仅仅是说“如果失败，只需抛出异常”。

抛出异常是昂贵的。

毕竟，如果抛出异常，而不是在抛出异常后将异常写入日志，最佳实践之一是在第一次机会异常处理程序中捕获它。例如：

ASP.NET：Global.asax Application_Error

其他：AppDomain.FirstChanceException 事件。

我的立场是，本地 try/catch 更适合处理特殊情况，您可以将异常转换为另一个异常，或者当您想在非常、非常、非常、非常、非常特殊的情况下“静音”它（库错误抛出一个不相关的异常，您需要静音才能解决整个错误）。

对于其余情况：

尽量避免异常。

如果这是不可能的：第一次机会异常处理程序。

或者使用 PostSharp aspect (AOP)。

就一些评论回复@thewhiteambit...

@thewhiteambit 说：

异常不是致命错误，它们是异常！有时它们甚至不是错误，但将它们视为致命错误是对异常是什么的完全错误的理解。

首先，异常怎么不能是错误？

没有数据库连接 => 异常。

解析为某种类型的无效字符串格式 => 异常

尝试解析 JSON，而输入实际上不是 JSON => 异常

预期对象时参数 null => 异常

某些库有错误 => 引发意外异常

有一个套接字连接，它会断开连接。然后你尝试发送消息 => 异常

...

我们可能会列出 1k 种抛出异常的情况，毕竟任何可能的情况都是错误的。

异常就是错误，因为归根结底，它是一个收集诊断信息的对象——它有一条消息，并且在出现问题时发生。

当没有异常情况时，没有人会抛出异常。异常应该是阻塞错误，因为一旦它们被抛出，如果你不尝试使用 try/catch 和异常来实现控制流，它们意味着你的应用程序/服务将停止进入异常情况的操作。

另外，我建议大家检查 fail-fast 范例published by Martin Fowler (and written by Jim Shore)。这就是我一直了解如何处理异常的方式，甚至在我前一段时间阅读本文档之前。

[...] 将它们视为致命错误是对异常是什么的完全错误的理解。

通常异常会切断一些操作流程，并对其进行处理以将其转换为人类可以理解的错误。因此，似乎异常实际上是处理错误情况并对其进行处理以避免应用程序/服务完全崩溃并通知用户/消费者出现问题的更好范例。

有关@thewhiteambit 问题的更多答案

例如，在缺少数据库连接的情况下，程序可以异常地继续写入本地文件，并在数据库再次可用时将更改发送到数据库。可以尝试使用 Exception 上的本地语言解释再次解析您无效的字符串到数字转换，就像您尝试将默认英语语言解析为 Parse("1,5") 失败并且您再次尝试使用德语解释时，这完全是很好，因为我们使用逗号而不是点作为分隔符。您会看到这些异常甚至不能被阻塞，它们只需要一些异常处理。

如果您的应用程序可能在不将数据持久化到数据库的情况下离线工作，则不应使用异常，因为使用 try/catch 实现控制流被视为反模式。离线工作是一个可能的用例，因此您实施控制流来检查数据库是否可访问，您不要等到它无法访问。解析的事情也是一个预期的情况（不是例外情况）。如果您期望这一点，则不要使用异常来执行控制流！。您从用户那里获得一些元数据以了解他/她的文化，并为此使用格式化程序！ .NET 也支持此环境和其他环境，但如果您希望应用程序/服务具有特定于文化的用法，则必须避免使用数字格式，这是一个例外。

未处理的异常通常会变成错误，但异常本身不是 codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

本文只是作者的观点或观点。

由于 Wikipedia 也可能只是文章作者的意见，我不会说这是教条，但请查看 Coding by exception 文章在某段某处所说的内容：

[...]使用这些异常来处理出现的特定错误以继续程序称为异常编码。这种反模式会迅速降低软件的性能和可维护性。

它还在某处说：

异常使用不正确

通常，异常编码可能会导致软件中出现异常使用不正确的进一步问题。除了对一个独特的问题使用异常处理之外，不正确的异常使用会通过执行代码甚至在引发异常之后更进一步。这种糟糕的编程方法类似于许多软件语言中的 goto 方法，但仅在检测到软件问题后才会出现。

老实说，我认为如果不认真对待用例，就无法开发软件。如果你知道...

您的数据库可能会脱机...

某些文件可以被锁定...

可能不支持某些格式...

某些域验证可能会失败...

您的应用应该在离线模式下工作...

无论用例...

...您不会为此使用例外。您将使用常规控制流来支持这些用例。

如果没有涵盖一些意想不到的用例，您的代码将很快失败，因为它会抛出异常。对，因为例外是例外情况。

另一方面，最后，有时您会涵盖抛出预期异常的异常情况，但您不会抛出它们来实现控制流。您这样做是因为您想通知上层您不支持某些用例，或者您的代码无法使用某些给定的参数或环境数据/属性。

---

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

异常和日志是给你的，开发者，而不是你的最终用户。在捕获每个异常时了解正确的做法远比仅仅应用一些黄金法则或依赖应用程序范围的安全网要好得多。

盲目的编码是唯一一种错误的编码。你觉得在这些情况下可以做一些更好的事情，这表明你已经投入到了良好的编码上，但要避免在这些情况下试图标记一些通用规则，并首先理解要抛出某些东西的原因以及什么你可以从中恢复过来。

---

我知道这是一个老问题，但这里没有人提到 MSDN 文章，并且实际上是为我清理了它的文档，MSDN 对此有一个very good document，当以下条件为真时，您应该捕获异常：

您对可能引发异常的原因有了很好的理解，并且可以实现特定的恢复，例如在捕获 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;     
}

我建议阅读整个“Exceptions and Exception Handling”部分以及Best Practices for Exceptions。

---

更好的方法是第二种方法（您指定异常类型的方法）。这样做的好处是您知道这种类型的异常可能发生在您的代码中。您正在处理这种类型的异常，您可以恢复。如果出现任何其他异常，则意味着出现问题，这将帮助您在代码中找到错误。应用程序最终会崩溃，但您会发现有一些您遗漏的东西（错误）需要修复。

---

有例外，我尝试以下方法：

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

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

在代码中，是这样的：

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
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

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

---

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

将其登录到文件\数据库等。尝试即时修复它（也许尝试执行该操作的替代方法）如果我们无法修复它，通知用户有一些错误，当然中止操作

---

对我来说，处理异常可以看作是业务规则。显然，第一种方法是不可接受的。第二个更好，如果上下文这样说，它可能是 100% 正确的方式。现在，例如，您正在开发 Outlook 插件。如果您的插件抛出未处理的异常，Outlook 用户现在可能知道它，因为 Outlook 不会因为一个插件失败而自行销毁。而且你很难弄清楚出了什么问题。因此，在这种情况下，第二种方法对我来说是正确的。除了记录异常，您可能会决定向用户显示错误消息——我认为这是一个业务规则。

---

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

但在现实生活中，当你想隐藏它时，你可能会遇到几种情况

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

---

您应该考虑这些例外设计指南

异常抛出

使用标准异常类型

异常和性能

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

---

没有任何参数的 catch 只是 吃 例外并且没有用处。如果发生致命错误怎么办？如果你不带参数地使用 catch ，就无法知道发生了什么。

catch 语句应该捕获更多特定异常，例如 FileNotFoundException，然后在最结束您应该捕获 Exception，它会捕获任何其他异常并记录它们。

---

有时您需要处理对用户无意义的异常。

我的方法是：

在应用程序级别（即在 global.asax 中）捕获关键异常的未捕获异常（应用程序不能有用）。这些例外我没有赶上这个地方。只需将它们记录在应用程序级别并让系统完成其工作。

抓住“就地”并向用户显示一些有用的信息（输入错误的数字，无法解析）。

抓紧时间，对诸如“我将在后台检查更新信息，但服务未运行”之类的边际问题不采取任何措施。

它绝对不一定是最佳实践。 ;-)

---

我可以告诉你一些事情：

Snippet #1 是不可接受的，因为它忽略了异常。 （它像什么都没发生一样吞下它）。

所以不要添加什么都不做或只是重新抛出的 catch 块。

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

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

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

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

int Parse(string input);

如果我们将无法解析的值传递给 int，此方法将抛出异常，而不是我们可能会编写如下内容：

bool TryParse(string input,out int result); <- 此方法将返回布尔值，指示解析是否成功。

也许这有点超出了这个问题的范围，但我希望这将有助于您在关于 try {} catch(){} 和例外情况时做出正确的决定。

---