如何将业务逻辑层错误消息封装到表现层，及ASP.NET Core限制异常抛出方法

一、业务逻辑层错误消息封装传递到表现层的可行方案 #

目前业内常用的有3种成熟方案，可根据项目复杂度选择：

• 自定义业务异常类
  继承基础Exception类扩展自定义字段，比如错误码、错误附加信息、业务场景标识等。业务层遇到业务规则不满足的场景直接抛出该自定义异常，表现层通过全局异常捕获机制读取异常中的错误信息即可完成传递。
  示例代码：

  public class BusinessException : Exception
  {
      public int ErrorCode { get; set; }
      public object ExtraInfo { get; set; }
      public BusinessException(int errorCode, string message, object extraInfo = null) : base(message)
      {
          ErrorCode = errorCode;
          ExtraInfo = extraInfo;
      }
  }
  

• 通用返回结果包装类
  定义泛型ApiResponse<T>统一结构作为业务层所有方法的返回值，包含是否成功、状态码、错误消息、返回数据四个核心字段。预期内的业务错误不需要抛出异常，直接返回标记为失败的包装类即可，表现层直接读取字段就能拿到错误信息。这种方案不需要走异常处理流，性能优于异常方案，是当前中小型项目的首选方案。
  示例代码：

  public class ApiResponse<T>
  {
      public bool IsSuccess { get; set; }
      public int Code { get; set; }
      public string Message { get; set; }
      public T Data { get; set; }
  
      public static ApiResponse<T> Success(T data, string message = "操作成功")
      {
          return new ApiResponse<T> { IsSuccess = true, Code = 200, Message = message, Data = data };
      }
  
      public static ApiResponse<T> Fail(int code, string message)
      {
          return new ApiResponse<T> { IsSuccess = false, Code = code, Message = message };
      }
  }
  

• 请求上下文传递
  利用ASP.NET Core内置的HttpContext.Items字典或者自定义的请求上下文对象，业务层将错误信息写入上下文，表现层直接从上下文中读取。这种方案适合需要跨多层传递错误上下文的复杂项目。

二、ASP.NET Core中限制异常抛出的常用方法 #

• 全局异常中间件捕获所有未处理异常
  在Program.cs中注册全局异常处理中间件，统一拦截所有未被捕获的异常，不需要在每个接口/方法中单独写try-catch，捕获后根据异常类型返回统一的友好提示，避免原生异常直接暴露到前端。
  示例代码：

  app.UseExceptionHandler(builder =>
  {
      builder.Run(async context =>
      {
          context.Response.StatusCode = StatusCodes.Status500InternalServerError;
          context.Response.ContentType = "application/json";
          var exceptionFeature = context.Features.Get<IExceptionHandlerPathFeature>();
          if (exceptionFeature?.Error is BusinessException businessEx)
          {
              await context.Response.WriteAsJsonAsync(new { code = businessEx.ErrorCode, msg = businessEx.Message });
              return;
          }
          // 非业务异常返回通用错误，生产环境禁止返回堆栈信息
          await context.Response.WriteAsJsonAsync(new { code = 500, msg = "服务器内部错误" });
      });
  });
  

• 异常筛选器精细化捕获控制器层异常
  实现IAsyncExceptionFilter接口自定义异常筛选器，仅针对控制器层的异常做捕获处理，适合需要对接口层异常做特殊定制的场景。
• 分环境配置异常页面
  开发环境启用DeveloperExceptionPage方便调试，生产环境强制关闭该页面，避免堆栈信息、数据库连接串等敏感信息泄露。
  示例代码：

  if (app.Environment.IsDevelopment())
  {
      app.UseDeveloperExceptionPage();
  }
  else
  {
      app.UseExceptionHandler("/Error");
      app.UseHsts();
  }
  

• 预期内错误优先用返回值代替异常抛出
  参数校验、业务规则校验等预期内的错误场景，优先使用前面提到的ApiResponse返回失败结果，不要抛出异常。异常仅用来处理非预期的系统级错误（比如数据库连接失败、第三方服务调用失败等），从根源减少不必要的异常抛出。

最佳实践：建议将两种方案结合使用，预期内的业务错误用返回包装类处理，非预期的系统错误用异常+全局捕获处理，兼顾性能、可维护性和安全性。

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