Throwing `errors`

[acoustic willow]

Perhabs I am missing something, but can somebody explain me why Amplify throws the GraphQL response when the reponse contains errors?

To me this is confusing for the following reasons:

• GraphQL may return (partial) data with the errors, this now comes in as an rejected promise;
• The response is nicely typed with Promise<GraphQLResult<T>> (or Observable), although the GraphQLResult<T> will never contain any errors on a successfull response;
• The promise rejection path for Promise<GraphQLResult<T>> is untyped (as always with Promises), making it hard to distinquish between exceptions and successful GraphQL requests (that happen to return one or more errors).

To me, the expected behaviour would be that:

• When a GraphQL request returns a valid GraphQLResult, just return it. Clients should check if errors is set or not;
• When the request cannot be made, or fails miserably, throw an error (like "No graphql endpoint provided").

Any feedback is appreciated 🙏

[summer portal]

Hello!
Since this is an opinionated question:
My opinion is that I don't want my app to receive a request that seems fine but with missing fields.
This means having to do the error check for each field

Fetching data with partial error should not be a normal case and therefore throw as you never want your app to run with this kind of application logic error.