一、什么是异常，我们为何需要它？

1. 编程世界里的“意外”

在C#中，异常是在程序执行期间发生的、中断了正常指令流的“反常”或“错误”事件。它不是我们通常所说的“BUG”（逻辑错误），比如你本想做加法却写了减法；也不是“语法错误”，那种在编译时就会被编译器指出的拼写错误。异常是运行时的错误，是程序在“活着”的时候遇到的突发状况。

常见的异常场景包括：

• 尝试打开一个不存在的文件。
• 网络连接突然中断。
• 请求的内存过大，系统无法分配。
• 数组索引超出了范围。
• 尝试对一个 null 的对象进行操作。

2. 异常的代价

• 程序突然终止：这是最直接的后果。对于用户来说，这意味着他们正在进行的工作（比如编辑文档、填写表单）可能会瞬间丢失，体验极差。
• 数据损坏：例如一个转账操作，在扣除A账户金额后、增加B账户金额前，程序因为一个异常而崩溃。这将导致账目不平，数据状态不一致。
• 暴露敏感信息：在Web应用中，一个未处理的异常可能会将包含数据库连接字符串、服务器内部路径等敏感信息的完整错误堆栈信息（Stack Trace）暴露给最终用户，构成严重的安全隐患。
• 资源泄露：如果程序在打开文件或数据库连接后，在关闭它们之前崩溃，这些宝贵的系统资源将无法被释放，久而久之会耗尽系统资源，导致整个系统变慢甚至瘫痪。

---

二、try-catch块的基础语法与工作原理

try-catch 语句是C#中用于处理异常的基本工具。它的逻辑非常符合人类的直觉：“尝试做某件事，如果出了问题，就这样补救”。

1. try 块：划定“风险区”

try 关键字后面跟着一个代码块 {}，我们将所有可能抛出异常的代码都放在这个代码块里。

try
{
    // 这里是“风险区”
    Console.WriteLine("请输入一个数字：");
    int number = int.Parse(Console.ReadLine());
    int result = 100 / number;
    Console.WriteLine($"100除以{number}的结果是：{result}");
} 
catch(Exception e)
{
    Console.WriteLine(e.ToString()); 
}

在上面的代码中，int.Parse() 可能会因为用户输入非数字字符而抛出 FormatException，而 100 / number 可能会因为用户输入0而抛出 DivideByZeroException。

2. catch 块：部署“应急预案”

catch 关键字紧跟在 try 块之后，它也包含一个代码块。当 try 块中的任何一条语句抛出异常时，程序的正常执行流会立即中断，然后CLR（公共语言运行时）会寻找一个能够“接住”这个异常的 catch 块。

最基本的 catch 块：

try
{
    // ... 风险代码 ...
}
catch
{
    // 异常发生时，执行这里的代码
    Console.WriteLine("发生了一个未知错误！");
}

这种不带任何参数的 catch 块可以捕获任何类型的异常，但它有一个巨大的缺点：你不知道具体发生了什么错误。这就像一个消防员赶到现场只知道“着火了”，却不知道是电线起火还是厨房起火，无法采取针对性的灭火措施。

3. 捕获具体的异常信息：catch (ExceptionType ex)

C#允许我们在 catch 后面指定要捕获的异常类型，并提供一个变量来接收这个异常对象。

System.Exception 是所有异常类型的基类。因此，catch (Exception ex) 可以捕获几乎所有类型的异常，并且通过变量 ex，我们可以访问到关于异常的宝贵信息。

try
{
    Console.WriteLine("请输入一个数组索引（0-2）：");
    int[] numbers = { 10, 20, 30 };
    int index = int.Parse(Console.ReadLine());
    Console.WriteLine($"索引 {index} 上的值为: {numbers[index]}");
}
catch (Exception ex)
{
    Console.WriteLine("\n--- 程序出现问题！---");
    Console.WriteLine($"错误类型: {ex.GetType().Name}"); // 获取异常的具体类型名
    Console.WriteLine($"错误信息: {ex.Message}");        // 获取异常的描述信息
    Console.WriteLine("--- 详细堆栈跟踪 ---");
    Console.WriteLine(ex.StackTrace);                  // 获取异常发生时的调用堆栈
    Console.WriteLine("----------------------");
}

Console.WriteLine("\n程序已通过异常处理，继续执行...");

---

三、玩转多catch块与异常层次结构

1. 多catch块进行细分异常

一个 try 块后面可以跟多个 catch 块，每个 catch 块负责处理一种特定类型的异常。CLR在匹配 catch 块时，会从上到下依次检查，并执行第一个能够匹配异常类型的 catch 块。

“匹配”的规则是：如果抛出的异常类型是 catch 块中声明的类型，或者是其子类，则匹配成功。

这就引出了多catch块最重要的规则：catch 块的顺序必须是从最具体（子类）到最通用（父类）。

示例：一个健壮的文件读取操作

public void ProcessFile(string filePath)
{
    try
    {
        string content = System.IO.File.ReadAllText(filePath);
        Console.WriteLine("文件内容处理成功！");
    }
    catch (System.IO.FileNotFoundException ex) // 最具体的异常
    {
        Console.WriteLine($"错误：文件 '{filePath}' 不存在。请检查路径是否正确。");
    }
    catch (System.UnauthorizedAccessException ex) // 另一个具体的异常
    {
        Console.WriteLine($"错误：程序没有权限访问文件 '{filePath}'。");
    }
    catch (System.IO.IOException ex) // 捕获其他所有IO相关的异常
    {
        Console.WriteLine($"读取文件时发生 I/O 错误: {ex.Message}");
    }
    catch (Exception ex) // 最后的“万能捕手”，捕获所有其他意想不到的异常
    {
        Console.WriteLine($"发生未知错误，请联系技术支持。");
        // 在真实应用中，这里应该记录完整的ex.ToString()到日志文件
        // Log.Error(ex.ToString()); 
    }
}

分析：

• 如果文件不存在，第一个 catch (FileNotFoundException) 会被执行。
• 如果文件存在但程序没有读取权限，第二个 catch (UnauthorizedAccessException) 会被执行。
• 如果发生其他I/O错误（如磁盘已满），由于这些错误类型（如DiskFullException）通常继承自 IOException，第三个 catch 块会被执行。
• 如果发生了完全无关的错误（比如在后续处理中出现 OutOfMemoryException），最后的 catch (Exception) 会作为兜底防线被触发。

如果你把 catch (Exception ex) 放在最前面，那么它会捕获所有异常，后面的具体 catch 块将永远没有机会执行，编译器甚至会因此报错。

2. 警惕空catch块和“吞噬”异常

有时候，你可能会看到这样的代码：

// 警告：极度危险的代码！
try
{
    SomeRiskyOperation();
}
catch (Exception)
{
    // 什么也不做
}

这被称为“吞噬异常”或“异常黑洞”。代码的作者可能认为“我知道这里可能出错，但我不关心”。这是一个极其危险的坏习惯！

为什么危险？

1. 隐藏问题：一个严重的问题（比如数据库连接失败）发生了，但程序假装什么都没发生，继续往下执行。这很可能导致后续代码在错误的数据基础上运行，引发更隐蔽、更难以调试的错误，甚至导致数据永久性损坏。
2. 调试噩梦：当程序出现奇怪的行为时，你将没有任何线索。没有日志，没有崩溃报告，错误就像人间蒸发了一样。

正确的做法是：即使你认为可以从某个异常中恢复，也至少应该记录它。

try
{
    // ...
}
catch (SomeExpectedAndRecoverableException ex)
{
    // 记录下来，以备后续分析
    Log.Warning($"一个可恢复的错误发生了: {ex.Message}"); 
    // 然后执行恢复逻辑
    // ...
}

3. TryParse vs. try-catch**

考虑一个场景：验证用户输入的字符串是否为有效的整数。我们有两种方法：

方法A: LBYL (Look Before You Leap) - 先看后跳 使用 int.TryParse 进行预检查。

string input = Console.ReadLine();
if (int.TryParse(input, out int number))
{
    // 成功，使用 number
    Console.WriteLine($"你输入的数字是: {number}");
}
else
{
    // 失败，处理无效输入
    Console.WriteLine("无效的输入，请输入一个整数。");
}

方法B: EAFP (It's Easier to Ask for Forgiveness than Permission) - 先做后问 直接尝试转换，用 try-catch 处理失败情况。

string input = Console.ReadLine();
try
{
    int number = int.Parse(input);
    // 成功，使用 number
    Console.WriteLine($"你输入的数字是: {number}");
}
catch (FormatException)
{
    // 失败，处理无效输入
    Console.WriteLine("无效的输入，请输入一个整数。");
}

如何选择？

1. 性能：抛出和捕获异常是一个非常昂贵的操作。CLR需要保存当前执行状态，展开调用堆栈，搜索 catch 块等，这比一个简单的 if-else 判断要慢得多。因此，在性能敏感的代码或错误是“可预期的常规事件”（比如用户输入错误）时，TryParse 模式是首选。
2. 代码清晰度：TryParse 明确地表达了“我正在尝试转换，并检查其结果”的意图，逻辑清晰。而使用 try-catch 来控制正常的程序流程，则被认为是一种反模式（anti-pattern），因为它混淆了“真正的异常情况”和“正常的逻辑分支”。
3. 适用场景：
   • 使用 TryParse：当失败是常见且可预期的分支时（如用户输入验证、检查字典中是否存在键）。
   • 使用 try-catch：当失败是真正“异常”的、不希望发生的情况时（如文件损坏、网络断开、磁盘已满）。

结论：不要用异常来控制程序流程。异常处理是为意外准备的，不是为日常准备的。

---

结语

点个赞，关注我获取更多实用 C# 技术干货！如果觉得有用，记得收藏本文