C#异常继承从设计原则到sealed关键字全解析

引言：异常，不仅仅是 try-catch

说起 C# 里的异常处理，很多人都会说“不就是 try-catch 嘛”，但真正把它玩明白的，其实并不多。这个看似基础的话题，背后藏着不少设计哲学——比如为什么自定义异常通常要标记为 sealed？这可不是一句“微软规定”就能打发的。今天我们就从异常继承的设计原则出发，结合电商订单系统的实战场景，把这个问题彻底讲透。

一、Exception 继承体系全景图

1.1 核心继承层次

System.Object
  └── System.Exception (抽象基类)
       ├── System.SystemException (CLR 抛出的异常)
       │    ├── NullReferenceException
       │    ├── IndexOutOfRangeException
       │    └── ...
       ├── System.ApplicationException (应用程序异常 - 已过时)
       └── 自定义异常 (继承自 Exception)

1.2 关键成员解析

public class Exception : ISerializable
{
    // 核心属性
    public string Message { get; }           // 异常说明
    public Exception InnerException { get; }  // 内部异常（链式）
    public string StackTrace { get; }         // 调用堆栈
    public MethodBase TargetSite { get; }     // 抛出异常的方法
    public IDictionary Data { get; }          // 额外键值对数据
    // 核心方法
    public virtual void GetObjectData(SerializationContext context);
    public Exception GetBaseException();       // 获取最内部异常
}

二、实战：设计一个三层架构的自定义异常体系

2.1 业务场景：电商订单系统

假设我们要开发一个订单处理系统，不同层级需要抛出有意义的异常——这样才能在 UI 层或日志中快速定位问题。

// 1. 基础自定义异常（抽象基类）
public abstract class OrderProcessingException : Exception
{
    public string OrderId { get; }
    protected OrderProcessingException(string message, string orderId) 
        : base(message)
    {
        OrderId = orderId;
    }
    protected OrderProcessingException(string message, string orderId, Exception inner)
        : base(message, inner)
    {
        OrderId = orderId;
    }
    // 支持序列化（用于跨 AppDomain 传递）
    protected OrderProcessingException(
        SerializationInfo info, StreamingContext context) 
        : base(info, context)
    {
        OrderId = info.GetString("OrderId");
    }
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        base.GetObjectData(info, context);
        info.AddValue("OrderId", OrderId);
    }
}
// 2. 具体业务异常 - 订单验证失败
public sealed class OrderValidationException : OrderProcessingException
{
    public List ValidationErrors { get; }
    public OrderValidationException(string orderId, List errors)
        : base($"订单 {orderId} 验证失败: {string.Join(", ", errors)}", orderId)
    {
        ValidationErrors = errors;
    }
}
// 3. 库存不足异常
public sealed class InsufficientInventoryException : OrderProcessingException
{
    public string ProductId { get; }
    public int RequestedQuantity { get; }
    public int A vailableQuantity { get; }
    public InsufficientInventoryException(string orderId, string productId, 
        int requested, int a vailable)
        : base($"产品 {productId} 库存不足 (需要: {requested}, 可用: {a vailable})", 
               orderId)
    {
        ProductId = productId;
        RequestedQuantity = requested;
        A vailableQuantity = a vailable;
    }
}
// 4. 支付失败异常
public sealed class PaymentFailedException : OrderProcessingException
{
    public string PaymentTransactionId { get; }
    public decimal Amount { get; }
    public string FailureReason { get; }
    public PaymentFailedException(string orderId, string transactionId, 
        decimal amount, string reason)
        : base($"订单 {orderId} 支付失败: {reason}", orderId)
    {
        PaymentTransactionId = transactionId;
        Amount = amount;
        FailureReason = reason;
    }
}

2.2 使用示例：分层异常处理

public class OrderService
{
    private readonly IOrderRepository _repository;
    private readonly IInventoryService _inventory;
    private readonly IPaymentGateway _payment;
    public async Task ProcessOrderAsync(string orderId)
    {
        try
        {
            // 1. 验证订单
            var order = await _repository.GetOrderAsync(orderId);
            ValidateOrder(order);
            // 2. 检查库存
            await ReserveInventoryAsync(order);
            // 3. 处理支付
            await ProcessPaymentAsync(order);
            // 4. 更新订单状态
            await _repository.UpdateOrderStatusAsync(orderId, "Completed");
        }
        catch (OrderValidationException ex)
        {
            // 业务层处理：记录验证失败，通知用户修改订单
            _logger.LogWarning(ex, "订单验证失败");
            throw; // 重新抛出，让上层 UI 处理
        }
        catch (InsufficientInventoryException ex)
        {
            // 尝试自动替换供应商或部分发货
            await HandleInventoryShortage(ex);
            throw; // 仍需要通知调用方
        }
        catch (PaymentFailedException ex)
        {
            // 记录支付失败，尝试其他支付方式
            await TryAlternativePayment(ex);
            throw;
        }
        catch (Exception ex)
        {
            // 捕获未知异常，包装为业务异常
            throw new OrderProcessingException(
                $"处理订单 {orderId} 时发生未知错误", orderId, ex);
        }
    }
    private void ValidateOrder(Order order)
    {
        var errors = new List();
        if (string.IsNullOrEmpty(order.CustomerId))
            errors.Add("客户ID不能为空");
        if (order.TotalAmount <= 0)
            errors.Add("订单金额必须大于0");
        if (errors.Any())
            throw new OrderValidationException(order.Id, errors);
    }
}

2.3 UI 层优雅处理

[ApiController]
public class OrderController : ControllerBase
{
    [HttpPost("{orderId}/process")]
    public IActionResult ProcessOrder(string orderId)
    {
        try
        {
            await _orderService.ProcessOrderAsync(orderId);
            return Ok(new { message = "订单处理成功" });
        }
        catch (OrderValidationException ex)
        {
            // 返回 400 并附带验证详情
            return BadRequest(new 
            { 
                error = ex.Message,
                validationErrors = ex.ValidationErrors,
                orderId = ex.OrderId 
            });
        }
        catch (InsufficientInventoryException ex)
        {
            // 返回 409 Conflict，提示用户调整数量
            return Conflict(new
            {
                error = ex.Message,
                productId = ex.ProductId,
                a vailable = ex.A vailableQuantity
            });
        }
        catch (PaymentFailedException ex)
        {
            // 返回 402 Payment Required
            return StatusCode(402, new { error = ex.Message });
        }
        catch (OrderProcessingException ex)
        {
            // 通用业务异常
            return StatusCode(500, new { error = ex.Message });
        }
    }
}

三、核心争议：为什么自定义异常要 sealed？

3.1 微软官方设计准则的明确规定

CA1064: Exceptions should be public

CA1032: Implement standard exception constructors

Do seal exception classes - 虽然没有独立的 CA 代码，但 .NET Core 源码分析和 Framework Design Guidelines 明确建议异常类应为 sealed。

3.2 Sealed 的四大核心理由

理由 1：防止异常多态的滥用

// 反模式 - 不应该这样做
public class DatabaseException : Exception { }
// 有人继承了它，改变了语义
public class SqlConnectionException : DatabaseException { }
public class SqlQueryException : DatabaseException { }
// 问题：catch(DatabaseException ex) 会捕获所有子类
// 导致无法精确处理特定错误

如果确实需要层次结构，应该使用不同的异常类型，而不是继承：

// 正确做法：独立的不相关异常
public sealed class SqlConnectionException : Exception { }
public sealed class SqlQueryException : Exception { }

理由 2：保持异常语义的原子性

// 未密封的异常
public class FileOperationException : Exception 
{
    public string FilePath { get; set; }
}
// 派生类可能修改重要属性
public class SpecialFileException : FileOperationException
{
    // 可能覆盖 FilePath 的语义，导致基类逻辑错误
    public new string FilePath { get; set; }
}
// 问题：基类的异常处理代码可能被破坏

理由 3：序列化与跨域边界传递

// 未密封的异常在跨 AppDomain 或跨进程序列化时
// 需要完整的类型信息，派生类可能破坏序列化契约
[Serializable]
public class MyException : Exception 
{
    // 如果没有正确实现序列化构造函数，派生类会失败
    protected MyException(SerializationInfo info, StreamingContext context)
        : base(info, context) { }
}
// 派生类可能忘记实现序列化构造函数
public class DerivedException : MyException { } // 危险！

理由 4：性能与代码稳定性

// JIT 编译器能对 sealed 类进行更好的优化
// 调用虚方法时无需检查派生类
public sealed class FastException : Exception 
{
    public override string Message => "Optimized";
}
// vs 未密封版本
public class VirtualException : Exception 
{
    public override string Message => "Needs vtable lookup";
}

3.3 什么时候可以不用 sealed？

极少数例外场景：

// 1. 抽象基类模式（本身不直接抛出）
public abstract class PluginException : Exception 
{
    protected PluginException(string message) : base(message) { }
}
// 2. 框架级别的公共异常基类（如 Prism 的 CompositePresentationException）
// 但这通常被认为是反模式
// 3. 测试 Mock 时需要（但测试应避免 Mock 异常）

3.4 实战对比：密封 vs 非密封

// ✅ 推荐：密封的完整异常
public sealed class ApiException : Exception
{
    public int StatusCode { get; }
    public string ApiPath { get; }
    public ApiException(string message, int statusCode, string apiPath)
        : base(message) => (StatusCode, ApiPath) = (statusCode, apiPath);
    private ApiException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
        StatusCode = info.GetInt32(nameof(StatusCode));
        ApiPath = info.GetString(nameof(ApiPath));
    }
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        base.GetObjectData(info, context);
        info.AddValue(nameof(StatusCode), StatusCode);
        info.AddValue(nameof(ApiPath), ApiPath);
    }
}
// 使用：清晰、安全、高性能
try { /* ... */ }
catch (ApiException ex) when (ex.StatusCode == 404)
{
    // 精确匹配，无需担心子类干扰
}

四、最佳实践总结

4.1 设计检查清单

• 异常类命名为 [Name]Exception
• 标记为 sealed（除非有充分理由）
• 实现三个标准构造函数（参数为 message、message+inner、序列化）
• 添加自定义属性时实现序列化支持
• 避免在异常属性中使用复杂的引用类型
• 异常类应该是 public（跨程序集使用）

4.2 构造函数模板

public sealed class MyException : Exception
{
    // 1. 无参构造函数（可选）
    public MyException() { }
    // 2. 带消息的构造函数
    public MyException(string message) : base(message) { }
    // 3. 带内部异常的构造函数
    public MyException(string message, Exception inner) : base(message, inner) { }
    // 4. 序列化构造函数（必须）
    private MyException(SerializationInfo info, StreamingContext context)
        : base(info, context) { }
}

4.3 抛异常 vs 返回值

// ❌ 避免：用返回码表示错误
public enum Result { Success, NotFound, ValidationError }
public Result ProcessOrder(string id) { /* ... */ }
// ✅ 推荐：使用异常
public void ProcessOrder(string id)
{
    if (string.IsNullOrEmpty(id))
        throw new ArgumentNullException(nameof(id));
    // ...
}
// ✅ 边界情况：预期内的失败用 Result 模式
public (bool Success, string ErrorMessage) TryParseOrder(string input) { /* ... */ }

五、性能考量与替代方案

5.1 异常的性能开销

// 异常很昂贵：堆栈跟踪收集 + 序列化 + CLR 内部处理
// 100,000 次异常抛出 ≈ 2-3 秒
// 100,000 次条件判断 ≈ 0.01 秒
// ✅ 高频路径避免异常
public bool TryGetValue(string key, out string value)
{
    if (_cache.ContainsKey(key))
    {
        value = _cache[key];
        return true;
    }
    value = null;
    return false;
}
// 而不是
public string GetValue(string key)
{
    if (!_cache.ContainsKey(key))
        throw new KeyNotFoundException(); // 如果频繁发生，性能灾难
    return _cache[key];
}

5.2 何时真正需要自定义异常

• ✅ 需要携带额外的业务数据（如订单ID、产品ID）
• ✅ 需要在日志系统中区分不同业务场景
• ✅ 需要特定于领域的中文错误信息
• ✅ 需要与第三方系统集成时的错误映射
• ❌ 仅仅为了给异常起个新名字
• ❌ 可以使用现有异常（如 InvalidOperationException）时
• ❌ 异常永远不会被 catch 区分处理时

结语：优雅异常的艺术

异常继承设计看似简单，实则体现了对系统边界、错误传播和代码可维护性的深刻理解。sealed 关键字在这里不是限制，而是保护——它防止了异常体系的无序膨胀，确保了每个异常类型的语义完整性和运行时稳定性。

记住：异常不是业务流程，而是业务规则的例外。当你的代码抛出异常时，应该让调用者无法忽视，同时提供足够的上下文信息。而 sealed 异常，就是这种清晰语义的最佳载体。

讨论：你是否有过因异常继承层次过深而导致的调试噩梦？欢迎在评论区分享你的经历和见解。