【.Net技术栈梳理】03-核心框架与运行时（异常处理）

1. 异常处理

异常处理是 .NET 运行时（CLR）提供的一种结构化、统一的方法，用于处理应用程序运行时发生的错误或其他意外情况。

其核心目的是将正常的业务逻辑与错误处理代码分离，提高代码的可读性和可维护性

1.1核心概念与机制

1.1.1 异常处理的关键组件

• 异常对象：所有异常都派生自 System.Exception 类。当一个错误发生时，CLR 或你的代码会创建（new）一个包含错误信息的异常对象实例，然后将其抛出（throw）。
• 抛出异常：使用 throw 关键字。这表示一个异常情况发生了，程序正常的执行流程被中断。

if (fileName == null)
    throw new ArgumentNullException(nameof(fileName));

• 捕获/处理异常： 使用 try-catch-finally 代码块。catch 块用于定义如何处理特定类型的异常。

try
{
    // 可能会抛出异常的代码
    File.ReadAllText("nonexistentfile.txt");
}
catch (FileNotFoundException ex)
{
    // 处理特定类型的异常
    Console.WriteLine($"文件未找到: {ex.FileName}");
}

• 清理资源：使用 finally 块。无论是否发生异常，finally 块中的代码总是会执行。这是释放资源（如关闭文件流、数据库连接）的理想场所。

FileStream file = null;
try
{
    file = File.OpenRead("file.txt");
    // 处理文件
}
catch (IOException ex)
{
    // 处理IO错误
}
finally
{
    // 无论是否异常，确保文件句柄被关闭
    file?.Close();
}

1.1.2 常见的异常类型层次结构

了解常见的异常类型是有效处理异常的基础。

• System.Exception： 所有异常的基类。
  • System.SystemException： CLR 或系统级操作抛出的异常的基类（通常不应由用户代码抛出）。
    • ArgumentNullException： 参数为 null。
    • ArgumentException及其子类： 参数无效。
    • IndexOutOfRangeException： 数组或集合索引越界。
    • NullReferenceException： 尝试对 null 引用进行操作（最常见的异常之一，通常意味着代码缺陷）。
    • StackOverflowException： 栈溢出（通常无法捕获）。
    • OutOfMemoryException： 内存不足（通常难以恢复）。
  • System.ApplicationException： （已过时，微软建议直接从 Exception 派生自定义异常）。
• 自定义异常： 可以创建自己的异常类来表示特定的应用程序错误，通常继承自 Exception。

1.2 工作机制与底层原理

1.2.1 异常处理的两阶段过程

.NET 的异常处理非常高效，其成本主要发生在异常实际被抛出时，而不是在代码中放置 try 块时。

1. 抛出阶段：

   • 当 throw 语句执行时，CLR 会立即中止当前的执行流程。
   • CLR 开始遍历调用栈（从当前方法开始，向上回溯到调用它的方法，依此类推），寻找一个能够处理该异常类型的 catch 块。

2. 捕获/展开阶段：

   • 一旦在调用栈的更高层找到了匹配的 catch 块，CLR 就会开始栈展开。
   • 栈展开： CLR 会回退调用栈，对于遍历到的每一个 try 块，如果有关联的 finally 块，就会执行其中的清理代码。这个过程会一直持续，直到到达找到的那个 catch 块为止。
   • 执行 catch 块中的处理代码。
   • 执行完成后，程序从 catch 块后的第一条语句继续执行。

如果代码中没有编写任何能够处理该异常的 catch 块，CLR 会继续其“栈展开”过程，直到遍历完整个调用栈。如果在整个调用栈中都找不到合适的 catch 块，那么这个异常就成为了一个“未处理的异常”。

此时，CLR 的默认行为是：终止整个应用程序进程。

详细分解这个过程：

第一阶段：栈展开 (Stack Unwind) - 无论如何都会发生
即使没有 catch 块，栈展开过程依然会发生。这是关键。

1. 异常抛出：在方法 MethodA 中，某行代码抛出了一个异常。
2. 查找处理程序：CLR 检查 MethodA 的当前执行点是否在 try 块内。如果是，它检查是否有与之关联的、能匹配异常类型的 catch 块。
   • 情况一：有 catch -> 执行 catch 块，然后程序从 catch 块后继续执行。
   • 情况二：无 catch 或 不匹配 -> CLR 会立即执行 MethodA 中当前 try 块所关联的 finally 块（如果有的话）。这是为了确保清理代码（如关闭文件、释放数据库连接）得到执行。
3. 向上回溯：执行完 finally 后，CLR 会退出 MethodA，返回到调用 MethodA 的方法（比如 MethodB）。
4. 重复过程：CLR 现在在 MethodB 的上下文中，重复步骤 2：检查 MethodA 的调用语句是否在 MethodB 的 try 块内？是否有匹配的 catch？
   • 如果有 -> 捕获并处理。
   • 如果没有 -> 执行 MethodB 中相应的 finally 块，然后继续退出 MethodB，回到它的调用者。

这个过程会一直持续，沿着调用栈一层一层地向上回溯，执行每一层中相应的 finally 块。

第二阶段：成为未处理异常并终止进程
如图末尾所示，当整个调用栈都被回溯完毕，依然没有找到任何能够处理这个异常的 catch 块时，异常就成为了一个“未处理异常”。

此时，CLR 会按以下顺序做出最后反应：

1. 触发 AppDomain.UnhandledException 事件：

   • 这是一个全局事件，是应用程序最后的“救命稻草”。你可以订阅这个事件，以便在应用程序崩溃前进行最后的日志记录、通知或其他清理工作。
   • 非常重要：在这个事件处理程序中，你无法阻止应用程序的终止。它只是一个通知机制。

2. 终止进程：

   • CLR 默认会立即终止当前的应用程序进程。这是一个“快速失败”的策略，旨在防止程序在损坏或不一致的状态下继续运行，从而导致数据丢失或其他更严重的问题。
   • 在控制台应用程序和 Windows 服务中，这会导致程序直接退出。
   • 在 ASP.NET Core 应用程序中，宿主通常会捕获这个异常，记录它，并终止当前请求（而不是整个进程），然后继续处理其他请求。这是宿主环境的一种保护机制。
   • 在 GUI 应用程序（如 WPF/WinForms）中，行为略有不同。默认情况下，未处理的异常也会导致进程终止。但有时你可能会看到一个错误对话框，这是因为应用程序的消息循环（Message Loop）可能会捕获并显示一些线程上的异常，但主线程上的未处理异常通常仍会导致应用退出。

总结与最佳实践

1. finally 块的可靠性：CLR 保证在栈展开过程中，finally 块中的代码一定会被执行。这是释放资源的关键。

2. 未处理异常的严重性：未处理的异常是致命的，会导致进程终止。

3. 如何应对：

   • 在最顶层进行全局捕获：对于可恢复的应用程序（如GUI应用、服务），应在应用程序的入口点（如 Main 方法）或使用全局事件（如 AppDomain.UnhandledException, TaskScheduler.UnobservedTaskException）来捕获所有未处理的异常，记录它们，并以一种可控的方式关闭应用程序（例如，告知用户并安全地保存数据），而不是让CLR突然终止它。

   • 不要隐藏错误：仅仅在顶层捕获所有 Exception 然后继续运行通常是一个坏主意，因为程序可能处于一个未知的不稳定状态。正确的做法是记录错误并优雅地重启。

1.2.2 异常与 CLR 的集成

.NET 的异常处理构建在操作系统底层结构化异常处理机制之上，但 CLR 对其进行了封装和管理，使其成为跨语言的标准：

• 语言无关性： 在 C# 中抛出的异常可以被 VB.NET 代码捕获和处理，反之亦然。
• 性能： 虽然抛出异常成本较高，但现代的 .NET JIT 编译器对异常处理路径进行了大量优化，使得没有异常发生时代码几乎没有任何性能开销。

1.3 工作机制与底层原理

错误的使用异常会导致代码难以维护和性能问题。以下是核心准则：

1.3.1 基本原则：抛出异常 vs. 返回错误码

• 对异常情况使用异常： 异常应用于处理意外的、非常规的错误情况（如文件不存在、网络断开、无效输入参数）。它们不应该用于控制正常的程序流程。
  • 错误示范： 使用异常来判断用户是否存在。
  • 正确示范： 使用返回值（如 bool）或 Try… 模式。

// 错误示范  错误！这是正常的控制流
try { FindUser("unknown"); }
catch (UserNotFoundException) { Console.WriteLine("用户不存在"); }

// 正确示范
if (TryFindUser("unknown", out var user))
  Console.WriteLine($"找到用户: {user.Name}");
else
  Console.WriteLine("用户不存在");

1.3.2 抛出异常的最佳实践

• 使用最有意义的异常类型： 不要总是抛出 Exception。使用 .NET 内置的、最具体的异常类型（如 ArgumentNullException, InvalidOperationException）。
• 提供有意义的错误消息： 异常消息应清晰说明错误原因，并包含相关参数的值。

// 好
throw new ArgumentNullException(nameof(fileName), "文件名不能为空，因为它用于生成最终报告。");
// 差
throw new Exception("出错啦！");

• 保护封装性： 不要在异常中泄露敏感信息（如密码、连接字符串、个人身份信息）。

1.3.3 捕获和处理异常的最佳实践

• 按需捕获，从具体到抽象： 只捕获你知道如何处理的异常类型。按从最具体到最一般的顺序排列 catch 块。

try { ... }
catch (FileNotFoundException ex) { ... } // 具体
catch (IOException ex)           { ... } // 较具体
catch (Exception ex)             { ... } // 最一般（谨慎使用！）

• 避免“吞掉”异常： 空的 catch 块是万恶之源。它隐藏了错误，使得调试变得极其困难。至少应该记录异常。

// 绝对禁止！
catch (Exception) { }

// 可接受的最低限度
catch (Exception ex)
{
    _logger.LogError(ex, "An error occurred while processing.");
    // 可能还需要决定是重新抛出还是继续执行
}

• 使用 throw; 而不是 throw ex; 重新抛出：

catch (Exception ex)
{
    _logger.LogError(ex, "Error");
    throw; // 正确！保留原始的调用栈信息
    // throw ex; // 错误！会重置调用栈，使调试变得困难
}

• 使用 when 关键字进行条件捕获： 可以基于异常的状态决定是否要处理它。

try { ... }
catch (HttpRequestException ex) when (ex.StatusCode == 404)
{
    // 只处理404错误
}
catch (HttpRequestException ex) when (ex.StatusCode == 500)
{
    // 只处理500错误
}

1.3.4 资源清理的最佳实践

• 优先使用 using 语句而不是 finally： 对于实现了 IDisposable 接口的对象，using 语句是更简洁、更安全的资源清理方式。它会在代码块结束时自动调用 Dispose() 方法，其底层就是编译成 try-finally 块。

// 推荐方式
using (var file = File.OpenRead("file.txt"))
{
    // 使用文件
} // 这里自动调用 file.Dispose()，即使发生异常

// C# 8.0+ 的using声明，作用域结束时自动Dispose
using var file = File.OpenRead("file.txt");
// 使用文件
```// 这里自动调用 file.Dispose()

1.4 性能考量

抛出异常是昂贵的操作，因为它涉及构建堆栈跟踪和遍历调用栈。因此：

• 不要用异常来实现常规逻辑（重申）。
• 对于可能频繁发生的、可预见的错误（如解析用户输入），使用 TryParse 这类模式而不是抛出异常。

// 高性能：对于无效输入，不会抛出异常
if (int.TryParse(userInput, out int result))
{
    // 使用 result
}
else
{
    // 处理无效输入
}

// 低性能：如果输入无效，会抛出异常
try
{
    int result = int.Parse(userInput);
    // 使用 result
}
catch (FormatException)
{
    // 处理无效输入
}

总结
.NET 的异常处理是一个强大而复杂的机制。有效使用它的关键在于：

1. 理解其原理：知道异常如何抛出、栈如何展开。
2. 遵循设计意图：仅对异常情况使用异常。
3. 掌握最佳实践：抛出具体的异常、按需捕获、使用 using 和 throw;、避免吞异常。
4. 关注性能：对高频可预见错误使用返回码/Try模式。

正确地使用异常处理，可以极大地提高程序的健壮性、可维护性和可调试性。