MVC控制器与支付服务类的异常处理最佳实践咨询

首先，咱们得抓住一个核心原则：关注点分离——不同层级处理不同类型的异常，让每个类只做自己擅长的事。下面针对你的问题逐个拆解：

1. 服务层（PaymentService）该做什么？ #

服务层是和第三方服务（比如Stripe）直接交互的地方，这里应该处理：

• 捕获Stripe特定异常：因为这是和Stripe交互的细节，控制器不需要知道底层用了Stripe还是其他支付网关，只需要知道“支付操作失败”这类业务级别的信息。
• 做底层异常的转换：把Stripe的具体异常（比如StripeException、CardException）包装成自定义的业务异常（比如PaymentFailedException、InvalidCardException），这样上层控制器不用依赖Stripe的具体类型。
• 必要的日志记录：记录和Stripe交互的详细错误信息，方便排查问题。
• 可选的重试逻辑：比如网络波动导致的重试，适合在服务层做。

修改你的服务层代码示例：

public class PaymentService : IPaymentService {
    private readonly ILogger<PaymentService> _logger;

    public PaymentService(ILogger<PaymentService> logger) {
        _logger = logger;
    }

    public async Task UpdateSomethingAsync(string id, string token) {
        try {
            // 和Stripe交互的代码
            await StripeService.UpdateCustomerAsync(id, token);
        } catch (CardException ex) {
            // 捕获卡片相关异常，记录日志
            _logger.LogError(ex, "Stripe卡片错误：{Message}", ex.Message);
            // 抛出业务级异常，带上友好提示
            throw new InvalidCardException("您的卡片信息无效，请检查后重试", ex);
        } catch (StripeException ex) {
            // 捕获其他Stripe异常
            _logger.LogError(ex, "Stripe操作失败：{Message}", ex.Message);
            throw new PaymentFailedException("支付服务暂时不可用，请稍后重试", ex);
        } catch (Exception ex) {
            // 捕获其他未知异常
            _logger.LogError(ex, "支付服务发生未知错误");
            throw new ApplicationException("系统异常，请联系管理员", ex);
        }
    }
}

// 自定义业务异常示例
public class InvalidCardException : Exception {
    public InvalidCardException(string message, Exception innerException) 
        : base(message, innerException) { }
}

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

2. 控制器层该做什么？ #

控制器是处理用户请求和响应的入口，这里应该处理：

• 捕获服务层抛出的业务级异常，返回友好的用户提示（比如ViewBag错误信息、JSON错误响应）。
• 不要处理底层技术细节的异常（比如Stripe的具体异常），因为控制器的职责是和用户交互，不是处理第三方服务的细节。
• 可选的用户端日志记录：记录用户看到的错误信息。

修改你的控制器代码示例：

public async Task<IActionResult> DoSomething(MyViewModel model) { 
    try { 
        await _paymentService.UpdateSomethingAsync(model.Id, model.Token); 
        return RedirectToAction("Success");
    } catch (InvalidCardException ex) {
        // 返回卡片错误的提示给用户
        ModelState.AddModelError("", ex.Message);
        return View(model);
    } catch (PaymentFailedException ex) {
        // 返回支付失败的提示
        TempData["ErrorMessage"] = ex.Message;
        return RedirectToAction("Error");
    } catch (ApplicationException ex) {
        // 返回系统异常提示
        TempData["ErrorMessage"] = ex.Message;
        return RedirectToAction("ServerError");
    }
}

3. 是否需要同时在控制器和服务类中用try/catch？ #

不是“必须同时用”，而是各司其职：

• 服务层的try/catch是为了处理底层技术细节（Stripe交互、网络错误等），并转换为业务异常。
• 控制器的try/catch是为了处理业务异常，给用户返回合适的响应。
  如果服务层不处理直接抛出原始异常，控制器就要处理所有细节，这会导致控制器依赖Stripe的类型，违反关注点分离，以后换支付网关时要改控制器代码，非常麻烦。

4. 是在服务层重新抛出还是所有处理放控制器？ #

最佳实践是服务层处理底层异常并转换为业务异常，控制器处理业务异常：

• 服务层重新抛出的应该是业务级异常，而不是原始的Stripe异常，这样上层不用关心底层实现。
• 不要把所有异常处理都放在控制器，否则控制器会变得臃肿，承担了不属于它的职责（处理第三方服务细节）。

总结一下：

• Stripe特定异常：在服务层捕获、记录、转换为业务异常。
• 业务级异常：在控制器捕获，返回用户友好响应。
• 不要让控制器依赖第三方服务的异常类型，保持代码的可维护性和扩展性。

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