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

2026-06-02 10:10:31 作者：周杰伦fans

本文深入探讨C#中自定义异常的设计原则,实战应用三层架构异常体系,并解析为何自定义异常应标记为sealed,通过电商订单系统示例,展示如何优雅处理异常,提升代码稳定性和维护性,感兴趣的朋友跟随小编一起看看吧

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

在 C# 开发中，异常处理是最基础却最容易被忽视的高级话题。很多开发者掌握了 try-catch-finally 的语法，却对异常的设计哲学知之甚少。本文将深入探讨自定义异常继承的设计原则、实战应用，以及一个看似矛盾的规范——为什么自定义异常通常要标记为 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 业务场景：电商订单系统

假设我们有一个订单处理系统，需要在不同层级抛出有意义的异常：

// 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<string> ValidationErrors { get; }
    public OrderValidationException(string orderId, List<string> 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 AvailableQuantity { get; }
    public InsufficientInventoryException(string orderId, string productId, 
        int requested, int available)
        : base($"产品 {productId} 库存不足 (需要: {requested}, 可用: {available})", 
               orderId)
    {
        ProductId = productId;
        RequestedQuantity = requested;
        AvailableQuantity = available;
    }
}
// 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<string>();
        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,
                available = ex.AvailableQuantity
            });
        }
        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 异常，就是这种清晰语义的最佳载体。

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

到此这篇关于C# 异常继承从设计原则到 sealed 关键字的奥秘的文章就介绍到这了,更多相关C# 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！