.NET Core Web API 注入服务向控制器抛自定义异常的实现咨询

关于通过接口暴露自定义异常的可行性 #

首先明确两个关键结论，直接回应你的核心认知误区：

• 你之前的思路存在偏差：我们根本不需要把自定义异常类做成接口的属性成员，就能实现「服务层抛出自定义异常、控制器层捕获」的逻辑。你之前觉得“接口无法将自定义类作为属性成员所以这条路走不通”的判断，本质上是把异常当成了需要通过接口传递的实例对象，而实际上异常是公开可访问的类类型，不需要接口持有它的任何成员就能被调用方捕获。
• 只要自定义异常类是public访问级别，且被服务层、控制器层共同引用（通常放置在项目的共享公共层，避免循环依赖），哪怕IMyService接口里没有任何和异常相关的声明，服务层抛出的异常也能被控制器正常捕获。

对应的最简实现示例：

// 公共共享层定义的自定义异常，全项目可访问
public class MyBusinessException : Exception
{
    /// <summary>
    /// 业务错误码
    /// </summary>
    public int ErrorCode { get; }

    public MyBusinessException(string message, int errorCode) : base(message)
    {
        ErrorCode = errorCode;
    }
}

// 业务接口正常定义方法，无需特意关联异常类型
public interface IMyService
{
    Task<Order> GetOrderAsync(long orderId);
}

// 服务实现层执行业务逻辑时抛出自定义异常
public class MyService : IMyService
{
    public async Task<Order> GetOrderAsync(long orderId)
    {
        if (orderId <= 0)
        {
            throw new MyBusinessException("订单ID参数不合法", 40001);
        }
        // 正常业务查询逻辑
    }
}

// 控制器层直接捕获对应异常，完成响应返回
[ApiController]
[Route("api/[controller]")]
public class MyController : ControllerBase
{
    private readonly IMyService _myService;
    public MyController(IMyService MyService)
    {
        _myService= MyService;
    }

    [HttpGet("{orderId}")]
    public async Task<IActionResult> GetOrder(long orderId)
    {
        try
        {
            var order = await _myService.GetOrderAsync(orderId);
            return Ok(order);
        }
        catch (MyBusinessException ex)
        {
            return BadRequest(new { code = ex.ErrorCode, message = ex.Message });
        }
    }
}

注意：不要把自定义异常类型定义在服务实现类的内部，否则其他项目层因为无法访问类的私有嵌套类型，会出现无法识别、无法捕获对应异常的问题。

现有设计思路的偏差与正确实践方向 #

逐个在控制器里写try-catch捕获服务异常的方式，在小规模项目中可以运行，但存在根本性的设计缺陷：

• 代码冗余度高：所有用到自定义服务的接口方法都要重复写相同的异常捕获逻辑
• 耦合性过强：异常处理逻辑和控制器业务代码深度绑定，新增错误类型时需要改动所有相关控制器
• 接口约定缺失：调用方无法从接口定义中获知业务方法可能抛出的异常类型，后期维护成本高

正确的服务层错误传递实践遵循以下原则：

• 异常类型统一归口：所有业务自定义异常统一放置在项目公共领域层，保证服务层、控制器层、中间件层可以无循环依赖地引用。
• 异常逻辑全局收敛：删除所有控制器内的重复try-catch代码，通过.NET Core内置的全局异常中间件/异常过滤器统一捕获服务层抛出的自定义异常，按照统一格式转换为HTTP响应，控制器只需要聚焦核心业务逻辑。
• 接口层补充异常约定：通过XML文档注释明确标注每个业务方法可能抛出的异常类型，让接口调用方可以清晰获知方法的错误场景，不需要阅读服务实现代码就能完成适配。
• 可选的显式错误传递方案：如果不希望通过异常传递业务错误，可以在服务层定义统一的ServiceResult<T>返回封装，将操作成功状态、错误码、错误消息直接作为返回值传递给控制器，由控制器根据返回值状态生成对应响应，这种方式可以减少非预期异常带来的性能损耗，错误逻辑的可追溯性更强。

内容的提问来源于stack exchange，提问作者Valhaal