Skip to content

Unclear how to distinguish between "intentional" and "server error" exception cases #79

@akdor1154

Description

@akdor1154

Heya,
I'm writing a server with the error philosophy that

  • if a resolver wants to return an "errors: {blah}" object to the client, I will handle this case explicitly (by some arbitrary method, e.g. raising a special Exception class, returning a special Error() result, etc)
  • any other exception in my server is "unexpected", and should be treated as a server error and result in a 500.

This is analogous to the pattern of Result (Ok, Error) in many functional languages. Result.Error is returned for an "expected" error, and potentially manually displayed to the client; any exceptions are "unexpected" and are truly exceptions in the sense that they define unexpected behaviour from my server and should hence not be exposed to clients.

It's unclear how I can achieve this with the error model of graphql-core-next. Some GraphQL errors are clearly of the second type (e.g. I've defined my schema incorrectly, GraphQLError('Type UnknownTransactionReturn must define one or more fields.')), but as far as I can tell, this library doesn't give me the ability to distinguish those from the first type (e.g. the user submitted a malformed graphql query).

Currently I am trying to achieve this by inspecting .errors in my ExecutionResults. (checking for original_error to see where GraphQL is hiding exceptions, etc.)

Is there any way to achieve the control over error behaviour that I am seeking here?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions