[SPR-9283] Improved support for REST API error reporting Created: 29/Mar/12  Updated: 15/Jan/19  Resolved: 21/Aug/12

Status: Resolved
Project: Spring Framework
Component/s: Web
Affects Version/s: 3.1.1
Fix Version/s: 3.2 M2

Type: Improvement Priority: Minor
Reporter: Keith Donald Assignee: Rossen Stoyanchev
Resolution: Complete Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to SPR-9290 Spring MVC: Guidance on reporting un-... Resolved
is related to SPR-9310 DefaultHandlerExceptionResolver doesn... Resolved
Days since last comment: 5 weeks, 3 days ago
Last commented by a User: true
Last updater: Spring Issuemaster


When implementing a REST API, Spring MVC provides full control over what ResponseEntity is returned to a client, which includes full support for setting custom HTTP status codes, response headers, and the response body. This is great and very flexible; however, the error reporting support in Spring MVC for common cases could be made more convenient.

Specifically, there is no way to auto-map an application business exception to a error response that contains all of the following bits of information: 1. an appropriate HTTP status code, and 2. a custom ErrorBody consisting of an application-specific error message and code. Yes, I know you can annotate an Exception with @ResponseStatus to specify which HTTP status code should be returned when that Exception is thrown. However, there is no ability to specify error data that should be returned in the body (message, code, etc) along with that. You can set a "reason" String, but unfortunately that is just passed off to HttpServletResponse#sendError(int, String) which isn't easily customized & by default generates a HTML response (not what you want with machine-to-machine communication--you typically want a JSON error body).

Facebook is an example of a REST API that returns a error body along with appropriate HTTP status codes in their API error responses e.g.:

   "error": {
      "message": "An active access token must be used to query information about the current user.",
      "type": "OAuthException",
      "code": 2500
  "error": {
    "message": "(#803) Some of the aliases you requested do not exist: whatever", 
    "type": "OAuthException", 
    "code": 803

It would be useful if Spring MVC had a documented way of throwing a business exception that automatically resulted in a error response with an appropriate HTTP status code plus a application/json response body containing a application-specific error message and error code.

Related, if a @Valid object validation failure could also be auto-mapped to an appropriate error structure (e.g. a 400 error status plus a body containing the field(s) in error along with messages and codes for each field error), that would be quite useful as well.

Comment by Rossen Stoyanchev [ 21/Aug/12 ]

SPR-9290 provides guidance on customizing the Servlet container error page, for cases when HttpServletResponse.sendError(int, String) is used (e.g. @ResponseStatus). SPR-9310 adds automatic handling for BindException.

There is also a new ResponseEntityExceptionHandler base class with an @ExceptionHandler method that handles standard Spring MVC exceptions. It's functionally equivalent to the DefaultHandlerExceptionResolver but returns a ResponseEntity (instead of a ModelAndView) and relies on message converters.

Comment by Pavel Orehov [ 11/Nov/12 ]

I'm trying to use that new feature but things does not work as expected.
Would appreciate any help.

Comment by Pavel Orehov [ 27/Nov/12 ]

It would be very helpful if I could also bind MethodHandler in exception handler method with @ExceptionHandler annotation.

Like the following code:

public ResponseEntity<Object> handleException(Exception ex, WebRequest request, MethodHandler handler)

{ ... }
Comment by Spring Issuemaster [ 14/Jan/19 ]

The Spring Framework has migrated to GitHub Issues. This issue corresponds to spring-projects/spring-framework#13921.

Generated at Fri Feb 22 01:56:31 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.