DispatcherServlet#setThrowExceptionIfNoHandlerFound doesn't work for REST application

[igilham]

This issue occurs in Spring Boot 1.1.12, 1.2.0, and 1.2.5. There are a few related answers on StackOverflow but none of them seem to work.

I'm trying to override the error handling behaviour to return a json-encoded custom POJO to the user when exceptions are thrown by the controllers in my application. This works for most exceptions but I can't get it to work with for 404s where there is no handler matching the path of the request.

Overriding the DispatcherServlet and setting setThrowExceptionIfNoHandlerFound to true does not result in the appropriate exception handler being called.

Here is my DispatcherServlet Bean declaration:

@Configuration
public class WebAppContext extends WebMvcConfigurerAdapter {

    @Bean(name = DispatcherServletAutoConfiguration.DEFAULT_DISPATCHER_SERVLET_BEAN_NAME)
    public DispatcherServlet dispatcherServlet() {
        DispatcherServlet ds = new DispatcherServlet();
        ds.setDetectAllHandlerAdapters(true);
        ds.setDetectAllHandlerExceptionResolvers(true);
        ds.setDetectAllHandlerMappings(true);
        ds.setDetectAllViewResolvers(true);
        ds.setThrowExceptionIfNoHandlerFound(true);
        return ds;
    }

// ... more Bean definitions
}

And here's part of the global Exception handler:

@ControllerAdvice(annotations = RestController.class)
public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {

    // TODO: figure out how to configure the DispatcherServlet's throwExceptionIfNoHandlerFound property so that this can work
    @Override
    protected ResponseEntity<Object> handleNoHandlerFoundException(NoHandlerFoundException ex, HttpHeaders headers, HttpStatus status, WebRequest request) {
        return new ResponseEntity<>(new CustomErrorType(HttpStatus.NOT_FOUND.value(), "Not Found"), HttpStatus.NOT_FOUND);
    }

// ... @ExceptionHandler methods etc.
}

I have also tried using the BeanPostProcessor interface to customise the DispatcherServlet as noted in a comment on an answer to this question, but that doesn't work either.

The documentation for how to handle global exceptions and customise the DispatcherServlet is incredibly obtuse. Am I missing something or is there a bug in there somewhere?

[philwebb]

We've clearly not done a great job at documenting this or making it particularly easy to use setThrowExceptionIfNoHandlerFound. I'll raise some new issues to address those points.

For your specific case I think that you can implement your own ErrorController to handle returning JSON. Looks at BasicErrorController for some inspiration. I tried adding this to one of the sample application and it appears to achieve what you need (assuming I've understood the issue correctly):

@Controller
@RequestMapping("${error.path:/error}")
public class CustomErrorController implements ErrorController {

    @Value("${error.path:/error}")
    private String errorPath;

    @Override
    public String getErrorPath() {
        return this.errorPath;
    }

    @RequestMapping
    @ResponseBody
    public ResponseEntity<Object> error(HttpServletRequest request) {
        HttpStatus status = getStatus(request);
        return new ResponseEntity<Object>(new CustomErrorType(status.value(), status.name()), status);
    }

    private HttpStatus getStatus(HttpServletRequest request) {
        Integer statusCode = (Integer) request.getAttribute("javax.servlet.error.status_code");
        if (statusCode == null) {
            return HttpStatus.INTERNAL_SERVER_ERROR;
        }
        return HttpStatus.valueOf(statusCode);
    }

}

$ curl -v -H "Accept: application/json" http://localhost:8080/missing
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> GET /missing HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.43.0
> Accept: application/json
> 
< HTTP/1.1 404 Not Found
< Server: Apache-Coyote/1.1
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Mon, 21 Sep 2015 18:37:01 GMT
< 
* Connection #0 to host localhost left intact
{"code":404,"message":"NOT_FOUND"}

[philwebb]

@igilham I've raised #3998, #3999 and #4000 to address some concrete things that we can do to improve this. Let me know if the solution above works for you and I'll close this one.

[igilham]

@philwebb I originally started with an ErrorController implementation and Spring Boot 1.1.12.

When I changed the Spring Boot dependency to 1.2.x, the behaviour changed in ways not documented in the migration notes, so I had to scour the web for a better alternative. Using @ControllerAdvice and custom @ExceptionHandlers seemed to be the most idiomatic way to handle application-defined exceptions. Extending ResponseEntityExceptionHandler should have allowed me to handle common framework-defined exceptions, like a 404 occurring due to there being no matching handler for a request.

Unfortunately, the mechanisms made available to customise the DispatcherServlet do not appear to work. As noted previously, there appears to be no way to call setThrowExceptionIfNoHandlerFound and expect it to actually do anything, as the framework ignores or overrules that decision.

Can you confirm if the ErrorController is the preferred and supported way to do this in the current version of the framework?

Can you advise me how to prevent the framework from calling sendError, instead letting the ErrorController handle an exception?

[philwebb]

When I changed the Spring Boot dependency to 1.2.x, the behaviour changed in ways not documented in the migration notes, so I had to scour the web for a better alternative.

I'm sorry about that, whatever the issue was we should have at least documented it.

Using @ControllerAdvice and custom @exceptionhandlers seemed to be the most idiomatic way to handle application-defined exceptions.

I agree, that does seem to be the best long-term solution. @rstoyanchev from the MVC team could probably confirm this.

Unfortunately, the mechanisms made available to customise the DispatcherServlet do not appear to work.

I'll double check this when looking into #4000 and make sure we add a test case or sample. I've not had time to dig deeper into this yet.

Can you advise me how to prevent the framework from calling sendError, instead letting the ErrorController handle an exception?

I will, as soon as I look into #4000 and check the MVC implementation details. My aim with suggesting that you use a custom ErrorController was to buy us a little time to look into this so that we can provide the best long-term solution for 1.3.

[rstoyanchev]

It sounds like when #4000 is resolved, it should be possible to use ResponseEntityExceptionHandler annotated with @ControllerAdvice consistently. If you want to implement your own REST API error handling it's indeed the most idiomatic Spring MVC way.

Nothing wrong with relying on the Boot provided ErrorController mechanism either for its default JSON responses or as a place to handle any other unhandled exceptions (e.g. from view rendering).

[igilham]

Thanks for your help @philwebb, @rstoyanchev.

For what it's worth, the undocumented behaviour changes I mentioned largely relate to Spring Security filtering and @ResponseStatus handling.

Using a custom GenericFilterBean in Boot 1.2 changes the accessibility of the Actuator endpoints, making it more difficult to fine-tune access control to business requirements.

The @ResponseStatus handling now exposes the reason field whereas it previously used the Exception's message property. This makes the mechanism less flexible overall, making it more difficult to provide context to the user via a simple Error Controller. This is the reason I started looking into the @ControllerAdvice and @ExceptionHandler approach.

[jasperblues]

👍 @ControllerAdvice stopped working recently. Just now hand-rolled error controller using example above. Mostly worked, but I need to dig the exception up in order to fill in some details. Will use BasicErrorController as example.

[jasperblues]

It turns out the exception is gone from the request - only the high level details are there. The workaround listed above doesn't help us - we need the exception so that we can map some information there onto our response object.

[wilkinsona]

@jasperblues Can you provide a small sample that illustrates your problem?