Typed Errors and Graphene

没有指定任何仓库文件、测试或入口点。首先查看 issue 中提出的 ErrorInterface、error union 和 mutation shape，然后与维护者确认这应该被记录为文档还是实现，以及哪些验收标准可以定义完成。

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:

{
  "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.

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

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:

    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!