在 REST 微服务上处理 Java 异常消息的替代方案？

Question

上下文：Java SpringBoot 公开 REST api

我有一个RestControllerAdvice，用于返回一个Response，其中包含业务逻辑期间可能发生的异常的消息：

@Slf4j
@RestControllerAdvice
@RequiredArgsConstructor
public class ExceptionRestController {

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler({ FunctionalRuntimeException.class })
    public DavinciApiResponse<Void> handleFunctionalRuntimeException(FunctionalRuntimeException exception) {
        DavinciApiResponse<Void> response = ExceptionUtils.buildResponse(exception);
        ExceptionUtils.logException(exception);
        return response;
    }

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler({ ValidationException.class,
                        ConstraintViolationException.class })
    public <E extends Exception> DavinciApiResponse<Void> handleValidationException(E exception) {
        DavinciApiResponse<Void> response = ExceptionUtils.buildResponse(exception);
        ExceptionUtils.logException(exception);
        return response;
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler(Exception.class)
    public DavinciApiResponse<Void> handleAllUncaughtException(Exception exception) {
        DavinciApiResponse<Void> response = ExceptionUtils.buildResponse(exception);
        ExceptionUtils.logException(exception);
        return response;
    }

}

前端团队是否应该使用异常消息将其显示给最终用户？ 从我的一点工作经验来看，我会说是的（这是我一直看到的方法），但我不太同意它......

示例1： 我需要开发一个多语言 Web 应用程序（英语 - 法语 - 西班牙语） 后端应该具有语言感知能力吗？ 我很确定答案是否定的。以用户指定的语言显示页面是前端的责任，因此向用户显示适当的错误消息是前端的工作。

示例2： 后端使用抛出运行时异常的开源库。 在这种情况下，也不可能直接操作异常消息，最多我必须通过将其作为参数传递给新的异常来包装它。

我正在考虑处理多语言异常消息的一个可能的解决方案是创建一个新的微服务来处理业务逻辑异常：

1. 微服务A前端调用API
2. API 上抛出了业务逻辑异常，因此它返回一个对象作为响应，其中包含 messageCode（用于标识消息的唯一代码）和 messageParams（消息代码的参数）
3. 前端然后调用“微服务业务逻辑异常”的 API，将包含 messageCode、messageParams 和语言的对象作为请求传递
4. “微服务业务逻辑异常”返回翻译为所需语言的异常消息，例如通过传递消息代码从数据库中提取消息。

如何处理异常消息？ 有哪些替代方案？

Answer 1

错误与非错误响应一样都是 REST API 的一部分。一切都是如此：java 方法的错误行为与非错误响应一样都是 java API 的一部分；只是人们发现很难考虑错误条件并变得懒惰，然后认为问题是“检查异常”作为一个概念，而不是编写正确的 API。因此，许多教程将异常视为事后的想法。

创建所有错误的正确（可能是分层的）描述并采取相应的行动。异常的 type 对于您的 API 来说是可以发回的。真正适合人类眼球的文本确实不是；这就是前端的工作。

作为后端开发人员，您的工作是明确列出可能发生的每个错误、发生的原因/时间、API 如何响应，并将前端可能需要的有关错误的任何详细信息添加到错误响应中。

根据您对 REST 概念的“忠实信徒”程度，您应该考虑用于所有这些错误的正确 HTTP 错误代码。如果问题主要是服务器上的问题，则应该是某个 5xx 错误。如果问题主要在于客户端的请求，则应该是 4xx，依此类推。