Typed Errors and Graphene

Hi folks,

I'm raising this issue to gauge ideas from the Python community on error handling best practices.

The usual way to handle errors in GraphQL is by inspecting the top-level `errors` key:

```json
{
"errors": {
# ... your error details ...
},
"data": null
}
```

However, this is usually problematic for API clients as they don't know **what to expect** from this `errors` key.
This means that error **discoverability** is impacted.

Another downside, is that the `data` key must be null when these high-level errors are raised.
In many situations API clients are interested in calling a mutation and, even if it fails, they'd like to receive data back. This data can be anything, but it's usually the object being mutated itself.

Another approach is extending upon this idea of typed errors that is strongly supported by Lee Byron as you can see [here](https://github.com/graphql/graphql-spec/issues/391#issuecomment-385553207).

This seems to solve both problems above (along with many others). Here's my take on what this would look like in Graphene:

```python
class ErrorInterface(graphene.Interface):
message = graphene.NonNull(graphene.String)

class ThingAErrorType(graphene.ObjectType):
class Meta:
interfaces = [ErrorInterface]

class ThingBErrorType(graphene.ObjectType):
class Meta:
interfaces = [ErrorInterface]

class MySweetMutationErrorUnion(graphene.Union):
class Meta:
types = [ThingAErrorType, ThingBErrorType]

class MySweetMutation():
error = graphene.Field(MySweetMutationErrorUnion)
output = graphene.Field(MySweetOutputType)

def mutate(self, info, input):
try:
thing_a = do_thing_a(input)
except ThingAException:
return MySweetMutation(error=ThingAErrorType())
try:
thing_b = do_thing_b(input)
except ThingBException:
return MySweetMutation(error=ThingBErrorType())
# happy path!
output = MySweetOutputType(thing_a=thing_a, thing_b=thing_b)
return MySweetMutation(output=output)
```

If we have a look at what the schema looks like, we have this:



And finally, API clients can query this mutation like this:

```graphql
mutation mySweetMutation($input: MySweetMutationInput!) {
mySweetMutation(input: $input) {
output {
# ....
}
error {
... on ThingAError {
__typename
message
}
... on ThingBError {
__typename
message
}
# We have an interface here so that we
# can extend the union with more errors without breaking
# backwards compatibility!!
__typename
message
}
}
}
```

I'm interested in your thoughts in this approach.
Thanks!

リポジトリのファイル、テスト、エントリポイントは指定されていません。まず、issue で提案されている ErrorInterface、error union、mutation shape を確認し、その後、これをドキュメント化するのか実装するのか、また完了の基準となる受け入れ基準は何かを maintainer と確認してください。

索引モデルが issue の本文から書いたものです。