Open alexstrat opened 5 years ago
Hmm, I think we need to distinguish here between errors that a user needs to handle and errors that are viable to work with. I would think that making everything a graphql type error would not leverage the paradigms rxjs helps us with.
What do you think about this approach?
Your suggestions:
100% agree with 4 and 5, and they are the most important! I think in 4, we also consider resolvers that return an Observable that end up throwing, right? myField: () => throwError(new Error())
The rest being more anecdotic and/or not clearly specified, so I don't have hard thoughts.
For 1, as discussed, for the reference, the specification is not clear and in the reference implementation, they decided to add any SyntaxError to the list of errors and to resolve normally the result with the errors
key.
I think in 4, we also consider resolvers that return an Observable that end up throwing, right?
Now we do 👍
I think this interface will have a nice usability, let's see when I have time to implement it, but it's my top priority on this project.
According to GrapqhQL specification, any error (missing field, resolver raises..) should be caught, formatted (
GraphQLError
type ingraphql-js
) and added to the "errors" list in the response.As of today, they are thrown in the observable error channel.