Error Handling Spring Boot Starter release 1.6.0

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:

package com.company.application.user;

public class UserNotFoundException extends RuntimeException {
    public UserNotFoundException() {
        super("User was not found");
    }
}

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=true

The 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.ConstraintViolationException is now also supported. This exception is used when you validate on a Service method for example, as opposed to validating the RequestBody in the Controller.
Validation annotations on a @RequestParam parameter now leads to the addition of parameterErrors in 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.