Handling errors

[triberraar]

I am trying to use the new feature to use ExceptionHandlers to map exceptions to nicer errors in graphql. I am not that successful with it though.

I changed graphql.servlet.exception-handlers-enabled to true and see that errors are handled differently, so that is good.

I then made my own handler for my own exception type I tried both:

@Configuration
class ErrorConfig() {

    @ExceptionHandler
    fun handle(exception: ClientException): ThrowableGraphQLError {
        return ThrowableGraphQLError(exception, exception.description)
    }

}

and

@Configuration
class ErrorConfig() {

    @Bean
    fun customErrorHandler() = CustomErrorHandler()

}

class CustomErrorHandler() {

    @ExceptionHandler(ClientException::class)
    fun handle(exception: ClientException): GraphQLError {
        return ThrowableGraphQLError(exception, exception.description)
    }

}

Neither seems to work. I debugged a bit and GraphQLErrorHandlerFactory seems to be the factory that makes the errorhandlers, which are used in GraphQLErrorFromExceptionHandler. However this factory is called before my bean is created which leads List<GraphQLErrorFactory> factories to be empty and default back to the default error.

Do i miss something?

[triberraar]

Also tried a third way:

@Component
class ErrorConfig() {

    @ExceptionHandler
    fun handle(exception: ClientException): ThrowableGraphQLError {
        return ThrowableGraphQLError(exception, exception.description)
    }

}

In this case it does seem that the GraphQLErrorHandlerFactory find this method, but it complains that the bean ErrorConfig doesn't exist yet.
So i have the feeling that the GraphQLErrorHandlerFactory runs too early?

[oliemansm]

Is it possible for you to share a small example project to reproduce this?

[triberraar]

Hej,
I can't make an example project atm (too many dependencies on our own custom stuff) But i can show how i solved it. In the end i made a component that looks like this:

@Component(value = "com.package.backofficegateway.error.CustomErrorConfig")
class CustomErrorConfig {

    @ExceptionHandler(ClientException::class)
    fun handle(exception: ClientException) = GraphQLExceptionHandler.handle(exception)

    @ExceptionHandler(ServerException::class)
    fun handle(exception: ServerException) = GraphQLExceptionHandler.handle(exception)

    @ExceptionHandler(FeignException::class)
    fun handle(exception: FeignException) = GraphQLExceptionHandler.handle(exception)

}

It was very important to give it the name like that. I think this is because the spring default name would have been customErrorConfig and then the GraphQLErrorHandlerFactory says there is no bean called com.package.backofficegateway.error.CustomErrorConfig.
We have a seperate module for this stuff and it tried making this class an @Configuration that makes a bean of type CustomErrorConfig in several ways, but i couldn't get it to work with @Configuration so that we could use a custom spring boot starter for this. But i couldn't get it to work with @configuration in any way so had to settle for @component.

Hope this helps.

[oliemansm]

@triberraar Thanks, it gives some direction. The problem is that I don't have a valid way to reproduce the issue however, so that'll cost me more time to write tests to reproduce this and fix it, and time is scarce atm.

[triberraar]

Yeah i understand. Since i have a workaround, i don't think you should stress too much about this.
Time is scarce at this end too, that is keeping me from giving you an example :(

[oliemansm]

I've implemented what I believe is a fix for this problem which is available in 5.4.1-SNAPSHOT. Before it would search for the annotation in classes defined as bean definitions, but now it searches in the actual beans. That should solve the naming issue. Please note that the method with the annotation needs to be in a bean, not in a @Configuration class. Could you check if this version works for you so we can close this issue?

[JonathanIlk]

Spring Components with the GraphQLErrorHandler interface get called correctly with version 5.4.1, so this issue can be closed.