Explain errors as data

[leebyron]

As suggested in graphql/graphql-js#560

Sometimes errors are totally expected and deserve to be represented as data in an API. This is worth a best practices post

[tspecht]

Any recommendations on this?

[anthonator]

How would you determine that the GraphQL response had errors? Would something like a boolean success field need to be introduced?

[felippenardi]

2016, 2017 and now 2018. Have we solved that already?

[j0nd0n7]

2016, 2017, 2019 and near 2020 and counting...

Today I've been reading how to improve the error handling of an existing API especially for user/expected errors.

First, it was important to me the opinion of @leebyron about the default "error system" that it is intended for unexpected errors. Check it here

The most recurrent flavors I read (besides using the default one) are:
"Shopify Flavor": For Mutations/Subscriptions use a custom payload type and include a field like userErrors field.
Shopify's GraphqlQL API Design best practices

"Medium/Sasha Solomon Flavor": Valid also for queries, use a UNION with the normal result plus new types that represents all the possible expected errors like "UserDeleted".
Sasha Solomon - Tech Talks

In this article both method are considered.
I Thought of a Better Way to Handle Errors

IMO with the experience collected from all the community so far in late 2019, the handling of "user/expected errors" should be standardized in the GRAPHQL spec (with op-in for current apis) instead of modeled with the current artifacts and applying different approaches.