Skip to content

Conversation

@karl-run
Copy link
Contributor

According to the graphql-java documentation, "Error while fetching data", it says:

If the exception you throw is itself a GraphqlError then it will transfer the message and custom extensions attributes from that exception into the ExceptionWhileDataFetching object. This allows you to place your own custom attributes into the graphql error that is sent back to the caller.

In graphql.execution.SimpleDataFetcherExceptionHandler, all exceptions are wrapped in a graphql.ExceptionWhileDataFetching. To maintain the functionality as described in the graphql-java-docs we need to check if the inner exception in graphql.servlet.DefaultGraphQLErrorHandler.java:47 is of type GraphQLError, in which case it should be a client error.

I'm not 100% sure of these assumptions, but in our case this would make sense. If not, we would have no way of passing errors through to the caller without implementing our own ExecutionStrategy.

Relates to #50.

@apottere
Copy link
Contributor

Good catch, thanks for the PR! I looked over the docs and this does look like the right thing to do.

@apottere apottere merged commit 3001c7a into graphql-java-kickstart:master Nov 28, 2017
@apottere
Copy link
Contributor

This is released in 4.6.1, syncing now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants