详解C#正确使用异常的六大原则

好的，我们来详细解析 C# 中正确使用异常的六大核心原则。遵循这些原则可以帮助你编写出更健壮、更易维护且性能更优的代码。

原则一：只在真正异常的场景中使用异常

这是最根本的原则：异常用于处理“异常”情况，即程序的执行流程意外地被中断或无法继续正常进行的错误情况。 它不应该被用来控制正常的业务逻辑流程。

错误示例：

// 错误：用异常来处理一个预期内、常见的业务情况（查找不到用户）
public User GetUserById(string userId)
{
    var user = _userRepository.Find(userId);
    if (user == null)
    {
        // 不要这样做！查找不到是正常业务流程，不是异常。
        throw new UserNotFoundException($"User with ID {userId} not found.");
    }
    return user;
}

// 调用方被迫使用 try-catch，代码冗长且逻辑混乱
try
{
    var user = GetUserById("123");
    // ... 使用 user
}
catch (UserNotFoundException)
{
    // 处理找不到用户的情况，但这本应是 if-else 就能搞定的逻辑
}

正确做法：
使用返回值（如 null）、Try-Parse 模式或可空类型来明确表示预期的失败状态。

// 正确：返回 null 或使用 Try 模式
public User? GetUserById(string userId) => _userRepository.Find(userId);

// 或者使用 Try 模式（如果操作复杂）
public bool TryGetUserById(string userId, out User user) => 
    _userRepository.TryFind(userId, out user);

// 调用方逻辑清晰，无需异常处理
var user = GetUserById("123");
if (user != null)
{
    // 正常使用
}
else
{
    // 优雅地处理“未找到”
}

何时才使用异常？

文件不存在（FileNotFoundException）
网络连接中断（IOException）
数据库连接失败（SqlException）
违反数据库约束（如唯一键冲突，DbUpdateException）
空引用访问（NullReferenceException，但通常应通过编码规范避免）
数组越界（IndexOutOfRangeException）

原则二：使用 finally 块或 `using` 语句进行资源清理

当代码中使用了非托管资源（如文件句柄、数据库连接、网络套接字）或实现了 IDisposable 接口的对象时，必须确保这些资源在使用后被正确释放，以防止内存泄漏或资源耗尽。

错误示例：

// 危险：如果在 try 块中发生异常，fileStream 可能无法被关闭
FileStream fileStream = null;
try
{
    fileStream = new FileStream("file.txt", FileMode.Open);
    // ... 操作文件
    throw new Exception("Something went wrong!"); // 模拟异常
    // fileStream.Close(); // 这行不会被执行
}
catch (Exception)
{
    // 处理异常
}
// fileStream 可能未被关闭！

正确做法 1：使用 finally 块

FileStream fileStream = null;
try
{
    fileStream = new FileStream("file.txt", FileMode.Open);
    // ... 操作文件
}
catch (Exception)
{
    // 处理异常
}
finally
{
    // 无论是否发生异常，都会执行
    fileStream?.Close();
}

正确做法 2（强烈推荐）：使用 using 语句
using 语句会在编译时转换为 try-finally 块，并自动调用对象的 Dispose() 方法，语法更简洁，更安全。

// 最简洁、最安全的方式
using (FileStream fileStream = new FileStream("file.txt", FileMode.Open))
{
    // ... 操作文件
} // 在此处自动调用 fileStream.Dispose()，即使发生异常也是如此

// C# 8.0 引入了 using 声明，作用域限定在局部范围末尾
using var fileStream = new FileStream("file.txt", FileMode.Open);
// ... 操作文件
// 在 fileStream 所在的方法或代码块结束时，会自动 Dispose

原则三：提供有意义的异常信息

抛出异常时，应提供足够的信息来帮助开发者或运维人员快速定位问题根源。一个好的异常消息应包含：是什么出了错、在什么情况下出错、以及相关的关键数据。

糟糕的异常消息：

throw new Exception("Error occurred."); // 毫无帮助
throw new ArgumentException("Invalid argument."); // 哪个参数？为什么无效？

良好的异常消息：

// 明确指出是哪个参数，并提供了无效的值
throw new ArgumentException($"User ID cannot be null or empty. Provided value: '{userId}'", nameof(userId));

// 包含导致计算失败的输入值
throw new InvalidOperationException($"Failed to calculate tax. Invalid amount: {amount}. Amount must be non-negative.");

// 记录关键上下文（注意不要记录敏感信息如密码）
throw new DbUpdateException($"Failed to save order {orderId} for customer {customerId}. See inner exception for details.", innerException);

原则四：优先捕获最具体的异常

在 catch 块中，应该从最具体的异常类型开始捕获，逐步过渡到更一般的异常类型。如果你先捕获了通用的 Exception，那么所有更具体的异常都将被它吞掉，导致你无法针对特定错误进行处理。

错误示例：

try
{
    // 可能抛出 FileNotFoundException, IOException, SecurityException...
}
catch (Exception ex) // 太宽泛！会捕获所有异常，包括非预期的异常如 OutOfMemoryException
{
    // 只能做非常泛化的处理，或者仅仅是记录日志
    Console.WriteLine("An error occurred: " + ex.Message);
}

正确做法：
按从具体到一般的顺序排列 catch 块。

try
{
    File.ReadAllText("config.json");
}
catch (FileNotFoundException ex)
{
    // 专门处理文件不存在的情况，例如创建默认配置
    Console.WriteLine($"Config file not found. Creating default. Path: {ex.FileName}");
    CreateDefaultConfig();
}
catch (UnauthorizedAccessException ex)
{
    // 专门处理权限不足的情况
    Console.WriteLine($"No permission to read config file. Error: {ex.Message}");
    // 可能需要提示用户以管理员身份运行
}
catch (IOException ex)
{
    // 处理其他 I/O 错误，如磁盘已满、文件被占用等
    Console.WriteLine($"I/O error reading config file: {ex.Message}");
}
catch (Exception ex) // 最后捕获真正的“兜底”异常
{
    // 记录未知错误，并可能重新抛出或进行紧急处理
    Console.WriteLine($"Unexpected error: {ex}");
    throw; // 重新抛出，让上层知道发生了未处理的异常
}

原则五：不要吞没异常（Empty Catch Blocks）

空的 catch 块（即捕获异常后什么都不做）是极其危险的，因为它会隐藏程序中发生的严重问题，使得调试变得不可能，程序可能在一种完全错误的状态下继续运行。

绝对禁止的做法：

try
{
    SomeOperation();
}
catch (Exception)
{
    // 静默吞没！什么都没做，问题被隐藏了。
    // 这会导致“幽灵”Bug，难以追踪。
}

如果必须“吞没”异常（极少数情况），务必记录日志：

try
{
    SomeOperation();
}
catch (SomeSpecificNonCriticalException ex)
{
    // 仅在确定这个异常不影响核心业务流程时使用
    // 并且必须记录日志！
    _logger.LogWarning(ex, "A non-critical error occurred during optional operation X. Continuing execution.");
    // 可以考虑设置一个默认值或执行降级逻辑
}

更好的做法是：至少重新抛出或包装异常。

catch (Exception ex)
{
    // 记录日志后重新抛出，保留堆栈信息
    _logger.LogError(ex, "Critical error in operation Y.");
    throw; // 重新抛出原始异常

    // 或者抛出一个新的、更有业务含义的异常，并将原异常作为内部异常
    // throw new BusinessLogicException("Unable to complete business process due to a data issue.", ex);
}

原则六：性能考量 – 异常应“昂贵”，控制流应“廉价”

异常的抛出和捕获在性能上是昂贵的操作。.NET 运行时需要收集线程的堆栈跟踪信息，这个过程很耗时。因此，绝不能用异常来代替常规的控制流（这与原则一紧密相关）。

错误示例（性能杀手）：

// 低效：每次循环都可能抛出异常来控制流程
for (int i = 0; i < items.Length; i++)
{
    try
    {
        if (items[i] == target) break;
    }
    catch (IndexOutOfRangeException) // 故意利用异常退出循环？荒谬！
    {
        break;
    }
}

正确做法：
使用条件判断等高效方式控制流程。

// 高效：使用明确的循环条件
for (int i = 0; i < items.Length; i++)
{
    if (items[i] == target) break;
}

结论： 让你的正常代码路径跑得飞快，把异常处理留给那些真正不常发生的“意外”。

总结

原则	核心思想	关键词
1. 只在异常场景使用	异常 ≠ 控制流	`null`, `Try-Parse`, 业务逻辑错误不用异常
2. 确保资源清理	防止资源泄漏	`finally`, `using`, `IDisposable`
3. 提供有意义信息	便于诊断问题	清晰的消息、相关参数、上下文
4. 捕获具体异常	精确处理错误	从具体到一般排序 `catch` 块
5. 不要吞没异常	避免隐藏 Bug	记录日志、重新抛出、永不空 `catch`
6. 注意性能	异常是昂贵的	异常用于意外，不用作流程控制