Allow custom `ExecutionStrategy` to use `DataFetcherExceptionResolver` chain

[JamesPeters98]

I've found a bug that occurs when using DataFetcherExceptionResolverAdapter and a custom QueryExecutionStrategy.

For some reason, if you return a failed future the exception just gets bubbled up without passing through DataFetcherExceptionResolverAdapter.

I've got a reproducible example here: https://github.com/JamesPeters98/SpringGraphQLErrorTest/

There is a Query and Mutation example. The mutation gets resolved correctly:

But not the query:

If you remove the custom QueryExecutionStrategy the exception gets resolved

[JamesPeters98]

Looking into this more, it appears to be because the custom QueryExecutionStrategy is missing the defaultDataFetcherExceptionHandler created in AbstractGraphQlSourceBuilder by Spring, but it doesn't seem that there's any way to access this from GraphQL Java.

I'm not sure what the best solution to this is? Maybe there should be a default Bean for DataFetcherExceptionHandler? Or add Getters for the exceptionResolvers field so we can create our own instance of ExceptionResolversExceptionHandler

Edit: ExceptionResolversExceptionHandler is also package private so that wouldn't work either.

[rstoyanchev]

Thanks for the sample. Yes, I see the challenge there. To create an ExecutionStrategy, you need a DataFetcherExceptionHandler, but our implementation is private and it's created inside GraphQlSource.Builder which accepts a list of DataFetcherExceptionResolver types.

We could expose a static factory method on DataFetcherExceptionResolver to create a DataFetcherExceptionHandler from a list of resolvers. Then you would inject ObjectProvider<DataFetcherExceptionResolver> into your bean method and use that to create the DataFetcherExceptionHandler to pass to the custom ExecutionStrategy.

[rstoyanchev]

I've added the factory method.

Note that the created handler does not have any state, other than the list of resolvers, so in that sense it just encapsulates the logic to invoke each in turn. It's not exposed publicly so it has no other configuration properties. In that sense it should be no issue if there are two or even more instance of it.

Also we already detect individual resolvers as beans, so it didn't seem ideal to make the handler a bean as well. It should work fine like, but if necessary we'll reconsider.