Spring Boot handles errors globally as JSON responses or HTML pages. This is powered by ErrorController and ErrorAttributes.
Spring Framework added support for Problem Details and Spring Boot auto-configures this as of #32634.
This issue is about rendering global errors in the problem details format consistently, as well as providing a path forward to making this the default in the future. This means that ErrorAttributes would need to produce a ProblemDetail or ErrorResponse instead of a Map. Also, we would probably need to revisit the backing infrastructure to better align with Framework. There are upcoming changes in Framework that could help us to improve the support and make it more lightweight, see https://github.com/spring-projects/spring-framework/issues/34272.
Comment From: kiruthiga1793
Hi @bclozel , I would like to collaborate. Can I work on this issue?
Comment From: bclozel
@kiruthiga1793 Thanks for the proposal but the issue is already assigned and I have a good chunk of changes ready. We're waiting for changes in Framework to complete this work.
Comment From: kiruthiga1793
@bclozel Thanks for letting me know. Add me also next time if possible if the issue has some sub tasks.
Comment From: danielrohe
Hi Brian,
in our company we implemented ErrorAttributes and ErrorView in a way that the Map structure resembled the JSON Problem structure for all spring framework exceptions and also added extension points for individual other exceptions. So I'm curious about the new improvement that come with Spring Framework and the way how exception handling will change in Spring Boot.
Comment From: bclozel
@danielrohe Is your application enabling problem details support in Spring Boot with the spring.mvc.problemdetails.enabled=true property? This should take care of handling most exceptions thrown by Spring Framework and render them as Problem Details responses in JSON or XML format with i18n support.
Currently, exceptions that are not handled at this point escape to the global Spring Boot error handling and are rendered as traditional Spring Boot errors. The goal of this issue if to make those problem details responses. Note, Spring Framework must first extend its error rendering support to render HTML error pages https://github.com/spring-projects/spring-framework/issues/34272.
Hopefully once this is all done, you won't have to maintain this custom error handling setup anymore as this will all be done for you.
Comment From: danielrohe
Hi Brian,
no, we didn't use Spring Framework's ProblemDetails support We implemented this approach of overwriting ErrorAttributes and ErrorView before Spring Framework supported Problem Details. This solution worked out quite well for all Spring Framework exceptions and also others like javax-validation's ConstraintViolationException for services that serve JSON and web (HTML) traffic. In addition we also have a Problem Details implementation at https://github.com/zalando/problem-spring-web that served pure backend services just serving JSON. For these services we can replace it with Spring Framework's Problem Details support as the responses are mostly similar. For the services that serve JSON and HTML we are using our implementation because the current Spring Framework does not support serving web (HTML) traffic. Therefore I'm curious what this new implementation will bring and whether its possible for users to utilize it for other framework exceptions like javax-validation's ConstraintViolationException.
Comment From: danielrohe
Hi Brian,
I did some more testing and a big difference between the current Error Response and the Error Attributes is that Error Responses does not include the binding results like FieldError. Is this also planned with the new feature?
Comment From: bclozel
@danielrohe I'm not sure I understand what you mean but this sounds like https://github.com/spring-projects/spring-framework/issues/34061
Comment From: danielrohe
Hi Brian, yes similar to the mentioned issue. In case of validation errors I think the API should still respond with a presentation of binding errors (e.g. JSON pointer to attribute, code and message) to provide e.g. JS frontends the possibility to display the error message (e.g. either mapped from code or taken from message) at the input field (identified by the JSON pointer) that caused the error. Similar to how Binding Errors (e.g. FieldError) work with backend rendering frameworks like thymeleaf.
Comment From: bclozel
@danielrohe that's not something that we can change in Spring Boot. This would require a change or new configuration option in Spring Framework. Maybe you can comment on that other issue and explain the use case? Thanks!
Comment From: jonenst
Hi, maybe specific documentation should be added in the meantime to https://docs.spring.io/spring-boot/reference/web/servlet.html#web.servlet.spring-mvc.error-handling (and/or maybe roadmaps for when future version may allow to do this more easily) for this use case of "always render as problemdetail (e.g. with fields title/detail/instance)". For exemple when the user code throws IllegalArgumentException or RuntimeException (which currently render in json with the old json format error/message).
My current understanding is to use "spring.mvc.problemdetails.enabled=true" and also a controllerAdvice for a global exception handler
@ExceptionHandler(Throwable.class)
public ProblemDetail handleAny(Throwable ex, HttpServletRequest request) {
// create and return populated problem detail here
}
but there's quite a bit of freedom in the code to create the problem detail in the global exeception handler so some official guidance for this specific use case would add a lot of value I think
ps: I think you can also define an ErrorAttributes bean that provides a map with the same keys as the fields in problem detail but this looks like it's less composable than defining an exceptionhandler that returns a problemdetail. I'm not sure though.