-
-
Notifications
You must be signed in to change notification settings - Fork 141
Description
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 ExecutionResult
s. (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?