Support for rendering exception response statuses in response codes

[dilipkrish]

    @RequestMapping
    public void someMethod() throws ResourceNotFoundException {...}

   @ExceptionHandler(ResourceNotFoundException)
   @ResponseStatus(HttpStatus.NOT_FOUND)
   void throw404() {...}

should generate 404 as a response status for declared exceptions

[omayevskiy]

👍 +1

[GitVhaos]

This feature would be awesome. Should be also supported when declaring @ExceptionHandler in "@ControllerAdvice" annotated classes.

[apomelov]

Awesome! Any plans for this issue?

[evgeny-konovalov]

+1

[alex-under]

+1

[ret0]

+1

[ianaz]

+1

[rmasgutov]

+1

[zacyang]

Hi all,
I am currently working on a project which requires this feature to generate swagger spec based on exception handler.
Therefore, I would like to try to fix this if no one picked up this issue yet.
Also, if there's any previous discussions regarding this issue regarding the potential approach, it would be helpful.
Thanks.

[dilipkrish]

Not sure that it is easy. So any approach you take, if you solve the problem we'd be glad to accept your contribution. Perhaps easier to do via some (custom or otherwise) annotations. At a high level the problem with controller exception handler is that there is no way to know if your controller does not use checked exception without additional annotations.

[benweet]

I couldn't find a way to the org.springframework.web.method.HandlerMethod (the java.lang.reflect.Method either) from the RequestMappingContext/OperationContext. Is it possible to expose one or the other so that we can work with it in our plugins ?

[dilipkrish]

@benweet that is intentionally protected from being exposed. Would you mind explaining how you're using the method and we can see if we can abstract that on one of those contexts

[benweet]

@dilipkrish I would have a class that implements the OperationBuilderPlugin interface and, inside the apply(OperationContext operationContext) method, I would list the operation exception via java.lang.reflect.Method.getExceptionTypes() (which I can't access at the moment). For each exception type, I would add a ResponseMessage to the OperationBuilder.

[dilipkrish]

@benweet isnt that implementation details that is better supported by adding support for @ExceptionHandler?

[benweet]

@dilipkrish I'm not really interested in @ExceptionHandler. My use case is to produce proper error message documentation for exceptions like this:

  @RequestMapping(
      method = RequestMethod.POST,
      path = "/api/requests",
      produces = "application/json")
  public RequestDto createRequest() throws InvalidApiKey {

@ResponseStatus(
    value = HttpStatus.FORBIDDEN,
    reason = "Unknown or missing API key.")
public class InvalidApiKey extends Exception {
}

And then implement the OperationBuilderPlugin like this:

  @Override
  public void apply(OperationContext operationContext) {
    ...
    // Get the java.lang.reflect.Method somehow
    for (Class exceptionType: method.getExceptionTypes())
      ResponseStatus responseStatus = errorType.getAnnotation(ResponseStatus.class);
      if (responseStatus != null) {
        HttpStatus httpStatus = responseStatus.value();
        // Build the ResponseMessage
        ...
    operationContext.operationBuilder().responseMessages(responseMessages);
    ...

[dilipkrish]

Ah got it, which is what this initial story was for. Thanks for clarifying. Yes, that requires that RequestMappingContext and consequently RequestHandler expose the exceptions in a way that doesnt leak implementation details. I added this feature request to the current version

[dlangerenken]

any volunteers? :)

[dilipkrish]

This is a little bit involved. Dont want to rush this into 3.0 which is due in a week