Clarify types of errors in spec text

[IvanGoncharov]

I noticed that all the errors mentioned in the specification could be divided into the following categories:

• syntax error
• validation error
• query error
• field error

I reviewed existing error mentions in the spec text and clarified their type.
In future, it would be great to add separate Errors types section to list all possible error types and describe them.

[stubailo]

I think to start, we could just group into:

1. Syntax
2. Validation
3. Execution

In your text you separate "query" from "field", but it seems like a lot of the examples are actually validation errors, right?

[leebyron]

I think the initial intent was for "query errors" to be errors having to do with the query itself (syntax or validation) while "field errors" were errors encountered while evaluating a field.

[leebyron]

Though a good clarification this PR makes is that query errors are not just syntax and validation but also variable coercion

[stubailo]

Hmm - I'm a bit worried about further overloading the word "query" - it's already hard to tell the difference between documents, operations, query operations, etc.

[leebyron]

Excellent point, @stubailo - I think perhaps "document" error might be a better fit. I think at Facebook we've also called these "fatal error" since they result in no execution result (no data key in response)

In terms of clarifying the spec, I definitely agree that defining the different kinds of errors is important (and could lead to error codes proposals in the future) but what is most important in this immediate context is the behavioral differences between them. In that sense there are really 2 behaviorally different errors - those that result in no data key, and those that are local to one field in the response.

[IvanGoncharov]

In that sense there are really 2 behaviorally different errors - those that result in no data key, and those that are local to one field in the response.

@stubailo @leebyron I think it very important to make it more explicit in the spec. For example, I was very surprised to find out that error during coercion of query variables is "fatal" error.

So I think error names should describe the expected result of errors instead of a place where they were originated.
What do you think about using partial error and fatal error?

[leebyron]

Merging since this is a pretty straightforward editing suggestion that's not changing anything - I still agree that the overall language around errors could be more clear