在本文中，我们介绍了 Micronaut 中的错误处理。处理错误的方法有很多种，包括处理异常或处理错误响应状态代码。我们还了解了如何在不同的范围（本地和全局）上应用处理程序。最后，我们通过一些代码示例演示了讨论的所有选项，并使用 Micronaut 测试来验证结果。
错误处理是开发系统时的主要关注点之一。在代码级别，错误处理处理我们编写的代码抛出的异常。在服务级别，错误是指我们返回的所有不成功的响应。
在大型系统中，以一致的方式处理类似的错误是一种很好的做法。例如，在具有两个控制器的服务中，我们希望身份验证错误响应相似，以便我们更容易调试问题。退一步说，为了简单起见，我们可能希望系统的所有服务都具有相同的错误响应。我们可以通过使用全局异常处理程序来实现这种方法。
在本教程中，我们将重点介绍Micronaut中的错误处理。与大多数 Java 框架类似，Micronaut 提供了一种常见的错误处理机制。我们将讨论这种机制，并在示例中演示它。
Micronaut 中的错误处理 在编码中，我们唯一可以想当然的事情就是错误会发生。无论我们编写的代码有多好，测试和测试覆盖范围有多明确，我们都无法避免错误。因此，如何在系统中处理它们应该是我们的主要关注点之一。通过使用状态处理程序和异常处理程序等一些框架功能，Micronaut 中的错误处理变得更容易。
如果我们熟悉Spring 中的错误处理，那么使用 Micronaut 的方式就很容易了。Micronaut提供了处理程序来处理抛出的异常，也提供了处理特定响应状态的处理程序。在错误状态处理中，我们可以设置本地范围或全局范围。异常处理仅在全局范围内进行。
值得一提的是，如果我们利用Micronaut 环境功能，我们可以为不同的活动环境设置不同的全局错误处理程序。例如，如果我们有一个发布事件消息的错误处理程序，我们就可以利用活动环境并跳过本地环境上的消息发布功能。
使用@Error注释在 Micronaut 中处理错误 在 Micronaut 中，我们可以使用@Error 注释定义错误处理程序。此注释在方法级别定义，它应该位于@Controller注释的类内。它具有与其他控制器方法类似的一些功能，例如它可以在参数上使用请求绑定注释来访问请求标头、请求正文等。
通过在 Micronaut 中使用@Error注释进行错误处理，我们可以处理异常或响应状态代码。这与其他流行的 Java 框架不同，后者仅为每个异常提供处理程序。
错误处理程序的一个特性是我们可以为它们设置一个范围。通过将范围设置为全局，我们可以让一个处理程序处理整个服务的 404 响应。如果我们不设置范围，则处理程序仅处理在同一个控制器中抛出的指定错误。
使用@Error注释处理响应错误代码 @Error注释为我们提供了一种处理每个错误响应状态的错误的方法。这样，我们可以定义一种通用方法来处理所有HttpStatus.NOT_FOUND响应，例如。我们可以处理的错误状态应该是在io.micronaut.http.HttpStatus枚举中定义的状态：
@Controller("/notfound")
public class NotFoundController {
@Error(status = HttpStatus.NOT_FOUND, global = true)
public HttpResponse<JsonError> notFound(HttpRequest<?> request) {
JsonError error = new JsonError("Page Not Found")
.link(Link.SELF, Link.of(request.getUri()));
return HttpResponse.<JsonError> notFound().body(error);
}
}
public class CustomException extends RuntimeException {
public CustomException(String message) {
super(message);
}
}
|
请注意，即使我们使用了@Controller注释，该控制器也没有指定任何HttpMethod，因此它不能完全像传统控制器一样工作，但它具有一些实现相似性，正如我们前面提到的。
现在假设我们有一个给出NOT_FOUND错误响应的端点：
@Get("/not-found-error")
public HttpResponse<String> endpoint1() {
return HttpResponse.notFound();
}
|
@Test
public void whenRequestThatThrows404_thenResponseIsHandled(
RequestSpecification spec
) {
spec.given()
.basePath(ERRONEOUS_ENDPOINTS_PATH)
.when()
.get("/not-found-error")
.then()
.statusCode(404)
.body(Matchers.containsString("\"message\":\"Page Not Found\",\"_links\":"));
}
|
需要澄清的一点是，如果我们将基本路径和路径更改为指向NotFoundController，因为此控制器中没有定义 GET ，只有错误，那么服务器就是抛出 404 的服务器，并且处理程序仍会处理它。
使用@Error注解处理异常 在 Web 服务中，如果未在任何地方捕获和处理异常，则控制器默认返回内部服务器错误。Micronaut 中的错误处理为此类情况提供了@Error注释。
让我们创建一个引发异常的端点和一个处理这些特定异常的处理程序：
@Error(exception = UnsupportedOperationException.class)
public HttpResponse<JsonError> unsupportedOperationExceptions(HttpRequest<?> request) {
log.info("Unsupported Operation Exception handled");
JsonError error = new JsonError("Unsupported Operation")
.link(Link.SELF, Link.of(request.getUri()));
return HttpResponse.<JsonError> notFound().body(error);
}
@Get("/unsupported-operation")
public HttpResponse<String> endpoint5() {
throw new UnsupportedOperationException();
}
|
如果我们到达这个端点，我们应该看到处理程序处理它并返回unsupportedOperationExceptions方法中定义的响应：
@Test
public void whenRequestThatThrowsLocalUnsupportedOperationException_thenResponseIsHandled(
RequestSpecification spec
) {
spec.given()
.basePath(ERRONEOUS_ENDPOINTS_PATH)
.when()
.get("/unsupported-operation")
.then()
.statusCode(404)
.body(containsString("\"message\":\"Unsupported Operation\""));
}
@Test
public void whenRequestThatThrowsExceptionInOtherController_thenResponseIsNotHandled(
RequestSpecification spec
) {
spec.given()
.basePath(PROBES_ENDPOINTS_PATH)
.when()
.get("/readiness")
.then()
.statusCode(500)
.body(containsString("\"message\":\"Internal Server Error\""));
}
|
在第二个示例中，我们从另一个控制器请求“/readiness”端点，该控制器也抛出了UnsupportedOperationException异常。由于此端点是在不同的控制器上定义的，因此本地处理程序不会处理该异常，因此我们得到的响应是默认的，错误代码为 500。
4. 使用ExceptionHandler接口在 Micronaut 中处理错误 Micronaut 还提供了实现ExceptionHandler接口的选项，以在全局范围内处理特定异常。这种方法要求每个异常一个类，这意味着默认情况下它们必须位于全局范围内。
Micronaut 提供了一些默认的异常处理程序，例如：
jakarta.validation.ConstraintViolationException com.fasterxml.jackson.core.JsonProcessingException |
如果需要的话，这些处理程序当然可以在我们的服务上被覆盖。
需要考虑的一件事是异常层次结构。当我们为特定异常 A 创建处理程序时，扩展 A 的异常 B 也将属于同一处理程序，除非我们为该特定异常 B 实现另一个处理程序。有关此内容的更多详细信息请参阅以下部分。
处理异常 如前所述，我们可以使用ExceptionHandler接口来全局处理特定类型的异常：
@Slf4j
@Produces
@Singleton
@Requires(classes = { CustomException.class, ExceptionHandler.class })
public class CustomExceptionHandler implements ExceptionHandler<CustomException, HttpResponse<String>> {
@Override
public HttpResponse<String> handle(HttpRequest request, CustomException exception) {
log.info("handling CustomException: [{}]", exception.getMessage());
return HttpResponse.ok("Custom Exception was handled");
}
}
|
现在假设我们有一个抛出CustomException的端点：
@Get("/custom-error")
public HttpResponse<String> endpoint3(@Nullable @Header("skip-error") String isErrorSkipped) {
if (isErrorSkipped == null) {
throw new CustomException("something else went wrong");
}
return HttpResponse.ok("Endpoint 3");
}
|
@Test
public void whenRequestThatThrowsCustomException_thenResponseIsHandled(
RequestSpecification spec
) {
spec.given()
.basePath(ERRONEOUS_ENDPOINTS_PATH)
.when()
.get("/custom-error")
.then()
.statusCode(200)
.body(is("Custom Exception was handled"));
}
|
根据层次结构处理异常 对于未明确处理的异常，如果它们扩展了具有处理程序的异常，则它们将由同一处理程序隐式处理。假设我们有一个扩展了CustomException的CustomeChildException：
public class CustomChildException extends CustomException {
public CustomChildException(String message) {
super(message);
}
}
|
@Get("/custom-child-error")
public HttpResponse<String> endpoint4(@Nullable @Header("skip-error") String isErrorSkipped) {
log.info("endpoint4");
if (isErrorSkipped == null) {
throw new CustomChildException("something else went wrong");
}
return HttpResponse.ok("Endpoint 4");
}
|
@Test
public void whenRequestThatThrowsCustomChildException_thenResponseIsHandled(
RequestSpecification spec
) {
spec.given()
.basePath(ERRONEOUS_ENDPOINTS_PATH)
.when()
.get("/custom-child-error")
.then()
.statusCode(200)
.body(is("Custom Exception was handled"));
}
|