Error handling

[mununki]

To open this issue here.. teamwalnut/graphql-ppx#202

[jeddeloh]

I plan on fixing this in #45.

[jfrolich]

Great yes. It's actually a good idea to try parsing it. The only concern is if we try parsing an incomplete result it can lead to type errors because some parse assumptions might be broken.

[jeddeloh]

Yes, that is the plan. I will attempt to parse data always, but it will become a result. Then when I go to unwrap the result, in the error case we will need to check that there is not already an error because we do not want to override the real error with a parse error.

[jeddeloh]

@mattdamon108 I'm not sure how urgent your situation is or whether changing your error policy fixed things, but this should now be fixed in #49 if you need it. I've published under reason-apollo-client@0.0.1-215abd6.0 or you could also install reason-apollo-client@dev. The only thing to be aware of is that promises are up in the air right now. They are currently Promise.t (reason-promise), but we may switch back to Js.Promise.t, provide some way to configure, or do something else entirely :) Sorry for the churn.

[mununki]

@jeddeloh Sorry for my late response. Please no hurry. Actually, I decided to make a workaround for the issue for a while. I changed the response type ship_request! -> ship_request to avoid gqlError handing for this time.

I'll look forward to the changes of Js.Promise.t

[jeddeloh]

This should be handled (attempting to parse partial data and returning a result instead of throwing exceptions) in v1.0.0-beta.0