Error Handling

[ngreenwood6]

I have been looking around at the source code and haven't come across a way to do this yet, so I figured I would reach out. I am trying to make multiple requests such as this:

{
  users {
    id,
    name
  },
  posts {
    id,
    title
  }
}

Now what I want to do is cause an error on just one of those queries and allow the other to continue. So ideally it would be nice if we could find out where the error was that way we could key the errors array like this:

array(
  'errors' => array(
    'users' => array(
    )
  )
)

Is there something I am missing here or is this really not possible to see which query threw the error right now?

[vladar]

There are several things to say about this:

1. Error in one field doesn't affect whole query if the type of this field is nullable. If it is non-nullable - GraphQL will find first nullable ancestor field and set it to null in response (and will add entry to errors). If there is no such ancestor - only then whole query fails and returns null.
   So in your example if field users is nullable then field posts will be still executed.
2. graphql-php returns plain list of errors versus nested as defined in spec - http://facebook.github.io/graphql/#sec-Errors Most of the time those errors are for debugging the query, not for consuming them in your app logic. These errors provide line and column position of field in query that produced error.

Some clients like Relay (and GraphiQL in future) - will expect errors in this form to assist developers in debugging.

But if you want to use custom errors in your app logic then you need to format errors yourself. Use GraphQL::executeAndReturnResult vs GraphQL::execute. Returned value will have errors property with array of entries of GraphQL\Error type, which in turn preserves original exception (you can access it with $error->getPrevious()).

As for hierarchy of errors - there is probably no easy way to reconstruct it right now (in theory this is possible with ASTs traversing and line/column matching, but not easy). I will likely add tools to make it easier one day, but no timeframes yet.

Also if you define custom error formatting - keep in mind that errors field in response is defined by specs, so for custom hierarchy of errors you should probably pick another field in response.