package com.company.application.user;
public class UserNotFoundException extends RuntimeException {
public UserNotFoundException() {
super("User was not found");
}
}Error Handling Spring Boot Starter release 1.6.0
Learn how to test real-world applications with the
Testing Spring Boot Applications Masterclass.
Comprehensive online course with 8 modules and 130+ video lessons to master well-known Java testing libraries: JUnit 5, Mockito, Testcontainers, WireMock, Awaitility, Selenium, LocalStack, Selenide, and Spring's Outstanding Test Support.
There is a new version 1.6.0 of the Error Handling Spring Boot Starter. A lot of new things have been added since I lasted blogged about version 1.2.0 of this library, so it is time for a round-up to show the new goodies.
New default error code generation strategy
Previous versions (before 1.5.0) used the full qualified name of the Exception class as the error code.
Suppose you had this exception:
This would generated this error response:
{
"code": "com.company.application.user.UserNotFoundException",
"message": "User was not found"
}Since 1.5.0, the default code uses the ALL_CAPS error code style by default, resulting in this error response:
{
"code": "USER_NOT_FOUND",
"message": "User was not found"
}The reason that the FQN was used before was that you are sure there are no name clashes. However, I believe the ALL_CAPS is a better default, and Twitter seems to agree:
What should be the default style for error codes in the error-handling library? https://t.co/4KyVSzEXBp
— Wim Deblauwe (@wimdeblauwe) March 30, 2021
If name clashes would happen, then there are enough override mechanisms in the library to deal with it.
HTTP response status in response body
By default, Spring Boot itself has the HTTP response status as a field in the JSON response body. Version 1.5.0 of the library now also added the possibility to enable this behaviour:
error.handling.http-status-in-json-response=trueThe resulting error response would be:
{
"status": 404, (1)
"code": "USER_NOT_FOUND",
"message": "Could not find user with id 123"
}| 1 | HTTP status code as field in the JSON response |
More support for validation problems
2 new features have been added to support error response related to validation:
-
The
javax.validation.ConstraintViolationExceptionis now also supported. This exception is used when you validate on aServicemethod for example, as opposed to validating theRequestBodyin theController. -
Validation annotations on a
@RequestParamparameter now leads to the addition ofparameterErrorsin the error response.
As an example, this contains the 3 possible types of validation errors that can happen:
{
"code": "VALIDATION_FAILED",
"message": "Validation failed for object='exampleRequestBody'. Error count: 4",
"fieldErrors": [
{
"code": "INVALID_SIZE",
"property": "name",
"message": "size must be between 10 and 2147483647",
"rejectedValue": ""
},
{
"code": "REQUIRED_NOT_BLANK",
"property": "favoriteMovie",
"message": "must not be blank",
"rejectedValue": null
}
],
"globalErrors": [
{
"code": "ValidCustomer",
"message": "Invalid customer"
},
{
"code": "ValidCustomer",
"message": "UserAlreadyExists"
}
],
"parameterErrors": [
{
"code": "REQUIRED_NOT_NULL",
"message": "must not be null",
"parameter": "extraArg",
"rejectedValue": null
}
]
}See Validation chapter in the documentation for full details.
New documentation website
There is a new documentation website at https://wimdeblauwe.github.io/error-handling-spring-boot-starter/
I am quite proud of the site, but it was really the spring-asciidoctor-backends project that made it possible.
It even has a light and a dark mode:
|
|
Conclusion
This concludes the overview of the recent changes to the Error Handling Spring Boot Starter. Feel free to create an issue or ping me on Twitter if you have a question or a problem with the library.
If you want to be notified in the future about new articles, as well as other interesting things I'm working on, join my mailing list!
I send emails quite infrequently, and will never share your email address with anyone else.