@bbakerman We currently use the ExecutionContext to pass authorization data to DataFetchers. Is there an alternative implementation for passing this type of per execution context to DataFetchers after this is released?

@cmonty thanks for your feedback: can you give use more details how you use it? Also just to be clear: the ExecutionContext is different from context in the DataFetcherEnvironment. I would expect that you use context (which is an Object) to pass down authorization data.

Thanks

@andimarek Ah, you're correct. We use env.getContext() to pass authorization data, which is the Object you described. Sorry for the confusion!

We do use ExecutionContext and call addError when an exception is thrown.

@cmonty

We do use ExecutionContext and call addError when an exception is thrown.

Come 12.0 this will be removed and we will ask you to return a DataFetcherResult wrapper object from your data fetchers

This exists today and it can contain data (or null) and errors (or empty list) and the graphql engine will put the errors in the result for you today.

https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/execution/DataFetcherResult.java

So if you move to that system before adopting 12.0 then you will continue to work as expected

Awesome, thanks for the information!

Hi, I have a question about this. We are trying to update our GraphQL code where we also use ExecutionContext.addError(). In the DataFetcherExceptionHandler implementation we want to catch a few specific exceptions and log them as warnings rather than errors. It looks like we can still do that but the return for DataFetcherExceptionHandlerResult requires GraphQL errors. Is there something I can use to convert the regular throwables to GraphQL errors.

@Salrandin - seae the answer above

Use https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/execution/DataFetcherResult.java

The allows you to send back errors from a data fetcher without throwing an exception.

I kinda get the solution but does this mean every datafetcher has its own responsibility for handling specific errors? The reason the implementation worked well was because we could handle it for all the datafetchers which kept our graphql instance uniform.