.NET中Exception类是异常基类，如何捕获特定异常？

.NET中的Exception类是所有异常的基类，提供错误消息、堆栈跟踪等信息；1. 捕获特定异常应使用try-catch块，先处理具体异常（如FormatException、OverflowException），再处理通用Exception，以实现精准错误处理；2. 不建议仅用catch(Exception ex)是因为会掩盖具体问题，导致调试困难，且可能引发异常吞噬，应针对可处理的特定异常进行捕获并采取恢复措施；3. 当标准异常无法表达业务逻辑错误时应自定义异常类（如继承Exception的InsufficientFundsException），以增强语义明确性、携带额外信息、便于捕获和提升可测试性；4. finally块用于确保代码无论是否发生异常都会执行，常用于资源释放（如关闭文件流）、解锁、状态重置或日志记录，而using语句则是IDisposable资源管理的try-finally语法糖，能自动调用Dispose方法，确保资源及时释放。理解并合理运用这些机制是编写健壮、可维护.NET应用的关键。

.NET中的Exception类是所有运行时错误或异常事件的基类，它定义了错误发生时携带的信息，比如错误消息、堆栈跟踪等。要捕获特定异常，你需要使用try-catch语句块，并在catch块中指定你想要处理的具体异常类型。通常的做法是先捕获更具体的异常，再捕获更通用的Exception。

在.NET开发中，Exception类是所有错误处理的起点。它不仅仅是一个简单的错误代码，而是一个包含丰富上下文信息的对象，能告诉你错误发生在哪里、为什么发生，甚至是什么导致了它。理解并有效利用Exception类，是编写健壮、可维护代码的关键一步。

我们处理异常的核心机制是try-catch块。try块包裹着你认为可能抛出异常的代码。如果try块中的代码确实抛出了一个异常，那么程序的控制流就会立即跳转到匹配的catch块。

举个例子，假设我们正在尝试将一个字符串转换为整数，但这个字符串可能不是有效的数字：

try
{
    string input = "abc";
    int number = int.Parse(input); // 这一行可能会抛出FormatException
    Console.WriteLine($"转换成功: {number}");
}
catch (FormatException ex)
{
    // 捕获特定异常：当字符串格式不正确时
    Console.WriteLine($"输入格式错误：{ex.Message}");
    // 可以在这里记录日志，或者给用户友好的提示
}
catch (OverflowException ex)
{
    // 捕获另一个特定异常：当数字太大或太小时
    Console.WriteLine($"数字超出范围：{ex.Message}");
}
catch (Exception ex)
{
    // 捕获所有其他未知异常。这通常放在最后。
    Console.WriteLine($"发生了未知错误：{ex.Message}");
    // 记录详细的堆栈跟踪信息，以便调试
    // Console.WriteLine(ex.StackTrace);
}
finally
{
    // 无论是否发生异常，这里的代码都会执行
    Console.WriteLine("尝试转换操作完成。");
}

这里我们先尝试捕获FormatException和OverflowException，它们比Exception更具体。如果不是这两种异常，才由最后的catch (Exception ex)来处理。这种多catch块的结构，能让我们针对不同类型的错误，采取不同的恢复策略，或者至少提供更精确的错误信息。

为什么不建议只用一个catch (Exception ex)？

只使用一个catch (Exception ex)来捕获所有异常，在很多情况下确实是需要避免的实践。虽然它能确保程序不会因为未捕获的异常而崩溃，但这种做法往往会掩盖具体的问题，导致代码变得难以调试和维护，甚至可能引入新的隐患。

想象一下，你写了一段代码，它既要从文件读取数据，又要通过网络发送数据。如果这段代码只用一个catch (Exception ex)来处理所有错误，那么当异常发生时，你很难立刻区分是文件找不到、文件权限不足，还是网络连接中断、服务器无响应。所有的错误都被一个泛泛的“发生了错误”给概括了。这就像医生看病，不问具体症状，只说“你病了”，然后开一张万能药方，显然是不负责任的。

更糟糕的是，有时开发者会捕获了异常，然后什么都不做（俗称“吞噬”异常）。这意味着一个潜在的严重问题可能在后台悄无声息地发生，直到系统行为变得异常，甚至数据损坏，你才发现。那时候，由于缺乏具体的错误信息，排查起来会非常困难，就像大海捞针。

所以，更推荐的做法是：尽可能捕获你预期会发生且能处理的特定异常。比如，文件操作就捕获FileNotFoundException、UnauthorizedAccessException；网络操作就捕获WebException、SocketException。这样，你就能针对性地处理这些已知问题，例如，文件找不到就提示用户重新选择路径，网络连接失败就尝试重试。对于那些你无法预料或无法处理的异常，再用一个通用的catch (Exception ex)来兜底，但即便如此，也应该至少记录下详细的错误信息（包括堆栈跟踪），以便后续分析。

什么时候应该自定义异常类？

当标准库中提供的异常类型无法准确表达你的应用程序中发生的特定业务逻辑错误时，就是你考虑自定义异常类的好时机。自定义异常能够让你的错误处理逻辑更加清晰、语义更丰富，并提升代码的可读性和可维护性。

举个例子，如果你的电商系统有一个购买商品的功能，当用户余额不足时，你可能会抛出一个异常。使用InvalidOperationException或者ArgumentException虽然也能表示错误，但它们并不能直接传达“余额不足”这个具体的业务含义。这时，定义一个InsufficientFundsException就非常有意义了。

public class InsufficientFundsException : Exception
{
    public decimal RequestedAmount { get; }
    public decimal AvailableBalance { get; }

    public InsufficientFundsException(decimal requestedAmount, decimal availableBalance)
        : base($"请求金额 {requestedAmount:C} 超过可用余额 {availableBalance:C}。")
    {
        RequestedAmount = requestedAmount;
        AvailableBalance = availableBalance;
    }

    public InsufficientFundsException(string message, Exception innerException)
        : base(message, innerException) { }

    // 也可以添加其他构造函数或属性
}

// 使用示例
public void PurchaseItem(decimal itemPrice, decimal userBalance)
{
    if (userBalance < itemPrice)
    {
        throw new InsufficientFundsException(itemPrice, userBalance);
    }
    // ... 执行购买逻辑
}

自定义异常的好处在于：

1. 明确的语义： 异常的名称本身就说明了错误的性质，无需查看代码或注释。
2. 携带更多信息： 你可以在自定义异常中添加额外的属性，比如上面例子中的RequestedAmount和AvailableBalance，这些信息对于捕获者处理异常非常有帮助。
3. 便于捕获和区分： 调用者可以精确地捕获你的自定义异常，并针对性地处理业务逻辑错误，而不是混淆在其他通用异常中。
4. 提高可测试性： 单元测试可以更容易地验证特定业务错误场景。

通常，自定义异常类会继承自System.Exception。如果你觉得这个异常只在你的应用程序内部有意义，也可以考虑继承System.ApplicationException，不过现在更常见的做法是直接继承Exception或者一个更具体的System异常（如果它能部分匹配你的场景）。

finally块的作用和使用场景是什么？

finally块在异常处理中扮演着一个非常重要的角色，它提供了一个无论try块中是否发生异常，其内部代码都保证会执行的区域。这使得finally块成为执行资源清理、状态重置等操作的理想场所。

最典型的使用场景就是资源的释放。在编程中，我们经常需要打开文件、建立数据库连接、获取网络流、或者申请内存等。这些资源在使用完毕后，通常都需要被显式地关闭或释放，以避免资源泄露，影响系统性能或导致其他问题。

考虑一个文件操作的例子：

System.IO.StreamReader reader = null; // 声明在try块外部，以便finally块可以访问
try
{
    reader = new System.IO.StreamReader("nonexistent.txt"); // 假设文件不存在，会抛异常
    string line = reader.ReadLine();
    Console.WriteLine(line);
}
catch (System.IO.FileNotFoundException ex)
{
    Console.WriteLine($"文件未找到: {ex.Message}");
}
catch (Exception ex)
{
    Console.WriteLine($"发生未知错误: {ex.Message}");
}
finally
{
    // 无论文件是否找到，是否读取成功，这个块都会执行
    if (reader != null)
    {
        reader.Close(); // 确保文件流被关闭
        Console.WriteLine("文件流已关闭。");
    }
}

在这个例子中，即使new System.IO.StreamReader抛出了FileNotFoundException，或者ReadLine()抛出其他异常，finally块中的reader.Close()代码也总会被执行。这保证了文件句柄不会被长期占用。

除了资源释放，finally块的其他常见用途包括：

• 解锁： 如果在try块中获取了某个锁（如线程锁），finally块可以用来保证锁被释放，避免死锁。
• 状态重置： 在某些复杂操作中，你可能需要临时改变一些全局或对象的状态，finally块可以确保这些状态在操作完成后被恢复到初始或预期状态。
• 日志记录： 记录操作的最终状态，无论成功与否。

值得一提的是，对于实现了IDisposable接口的资源，C#提供了一个更简洁的语法糖——using语句。using语句本质上就是try-finally块的语法糖，它能确保IDisposable对象的Dispose()方法在离开using块时被调用，无论是否发生异常。这在很多情况下比手动编写finally块更方便和安全。

// 使用using语句的例子，等同于上面的try-finally
try
{
    using (System.IO.StreamReader reader = new System.IO.StreamReader("nonexistent.txt"))
    {
        string line = reader.ReadLine();
        Console.WriteLine(line);
    } // reader.Dispose() 会在这里自动调用
}
catch (System.IO.FileNotFoundException ex)
{
    Console.WriteLine($"文件未找到: {ex.Message}");
}
catch (Exception ex)
{
    Console.WriteLine($"发生未知错误: {ex.Message}");
}

理解finally块的保证执行特性，对于编写健壮、资源管理得当的应用程序至关重要。