Add sub-sections for 'request errors' and 'field errors' and update links

Author: leebyron

spec/Section 3 -- Type System.md

@@ -280,7 +280,7 @@ A GraphQL schema may describe that a field represents a list of another type;
 the `List` type is provided for this reason, and wraps another type.
 
 Similarly, the `Non-Null` type wraps another type, and denotes that the
-resulting value will never be {null} (and that an error cannot result in a
+resulting value will never be {null} (and that a field error cannot result in a
 {null} value).
 
 These two types are referred to as "wrapping types"; non-wrapping types are
@@ -375,7 +375,8 @@ all built-in scalars must be omitted for brevity.
 
 A GraphQL service, when preparing a field of a given scalar type, must uphold the
 contract the scalar type describes, either by coercing the value or producing a
-field error if a value cannot be coerced or if coercion may result in data loss.
+[field error](#sec-Errors.Field-errors) if a value cannot be coerced or if
+coercion may result in data loss.
 
 A GraphQL service may decide to allow coercing different internal types to the
 expected return type. For example when coercing a field of type {Int} a boolean
@@ -399,7 +400,8 @@ information on the serialization of scalars in common JSON and other formats.
 
 If a GraphQL service expects a scalar type as input to an argument, coercion
 is observable and the rules must be well defined. If an input value does not
-match a coercion rule, a [request error](#sec-Request-Errors) must be raised.
+match a coercion rule, a [request error](#sec-Errors.Request-errors) must be
+raised (input values are validated before execution begins).
 
 GraphQL has different constant literals to represent integer and floating-point
 input values, and coercion rules may apply differently depending on which type
@@ -1516,8 +1518,8 @@ type of an Object or Interface field.
 The value for an input object should be an input object literal or an unordered
 map supplied by a variable, otherwise a request error must be raised. In either
 case, the input object literal or unordered map must not contain any entries
-with names not defined by a field of this input object type, otherwise an error
-must be raised.
+with names not defined by a field of this input object type, otherwise a
+response error must be raised.
 
 The result of coercion is an unordered map with an entry for each field both
 defined by the input object type and for which a value exists. The resulting map
@@ -1632,12 +1634,12 @@ implementation.
 
 If a list's item type is nullable, then errors occurring during preparation or
 coercion of an individual item in the list must result in a the value {null} at
-that position in the list along with an error added to the response. If a list's
-item type is non-null, an error occurring at an individual item in the list must
-result in a field error for the entire list.
+that position in the list along with a field error added to the response.
+If a list's item type is non-null, a field error occurring at an individual item
+in the list must result in a field error for the entire list.
 
-Note: For more information on the error handling process, see "Errors and
-Non-Nullability" within the Execution section.
+Note: See [Handling Field Errors](#sec-Handling-Field-Errors) for more about
+this behavior.
 
 **Input Coercion**
 

spec/Section 6 -- Execution.md

@@ -347,8 +347,8 @@ resolving to {null} if allowed or further propagated to a parent field.
 If this occurs, any sibling fields which have not yet executed or have not yet
 yielded a value may be cancelled to avoid unnecessary work.
 
-See the [Errors and Non-Nullability](#sec-Errors-and-Non-Nullability) section
-of Field Execution for more about this behavior.
+Note: See [Handling Field Errors](#sec-Handling-Field-Errors) for more about
+this behavior.
 
 ### Normal and Serial Execution
 
@@ -714,19 +714,27 @@ MergeSelectionSets(fields):
   * Return {selectionSet}.
 
 
-### Errors and Non-Nullability
+### Handling Field Errors
 
-If an error is raised while resolving a field, it should be treated as though
-the field returned {null}, and an error must be added to the {"errors"} list
-in the response.
+["Field errors"](#sec-Errors.Field-errors) are raised from a particular field
+during value resolution or coercion. While these errors should be reported in
+the response, they are "handled" by producing a partial response.
+
+Note: This is distinct from ["request errors"](#sec-Errors.Request-errors) which
+are raised before execution begins. If a request error is encountered, execution
+does not begin and no data is returned in the response.
+
+If a field error is raised while resolving a field, it is handled as though the
+field returned {null}, and the error must be added to the {"errors"} list in
+the response.
 
 If the result of resolving a field is {null} (either because the function to
-resolve the field returned {null} or because an error occurred), and that
+resolve the field returned {null} or because a field error was raised), and that
 field is of a `Non-Null` type, then a field error is raised. The
 error must be added to the {"errors"} list in the response.
 
-If the field returns {null} because of an error which has already been added to
-the {"errors"} list in the response, the {"errors"} list must not be
+If the field returns {null} because of a field error which has already been
+added to the {"errors"} list in the response, the {"errors"} list must not be
 further affected. That is, only one error should be added to the errors list per
 field.
 

spec/Section 7 -- Response.md

@@ -7,21 +7,13 @@ operation if successful, and describes any errors raised during the request.
 A response may contain both a partial response as well as any field errors in
 the case that a field error was raised on a field and was replaced with {null}.
 
-## Request Errors
-
-Any errors raised during a GraphQL request are termed "request errors."
-Request errors are not limited to errors that were raised during execution of the
-operation, they could be raised during parsing and validation of the request
-too. For example, a request error will be raised if the request does not
-contain sufficient information to indicate uniquely which operation to execute.
-
 ## Response Format
 
 A response to a GraphQL request must be a map.
 
 If the request raised any errors, the response map must contain an
 entry with key `errors`. The value of this entry is described in the "Errors"
-section. If the operation completed without raising any errors, this entry
+section. If the request completed without raising any errors, this entry
 must not be present.
 
 If the request included execution, the response map must contain an entry
@@ -73,6 +65,30 @@ If the `data` entry in the response is present (including if it is the value
 were raised during execution. If field errors were raised during execution, it
 should contain those errors.
 
+**Request errors**
+
+Request errors are raised before execution begins. This may occur due to a parse
+grammar or validation error in the requested document, an inability to determine
+which operation to execute, or invalid input values for variables.
+
+Request errors are typically the fault of the requesting client.
+
+If a request error is raised, execution does not begin and the `data` entry in
+the response must not be present. The `errors` entry must include the error.
+
+**Field errors**
+
+Field errors are raised during execution from a particular field. This may occur
+due to an internal error during value resolution or failure to coerce the
+resulting value.
+
+Field errors are typically the fault of GraphQL service.
+
+If a field error is raised, execution attempts to continue and a partial result
+is produced (see [Handling Field Errors](#sec-Handling-Field-Errors)).
+The `data` entry in the response must be present. The `errors` entry should
+include all raised field errors.
+
 **Error result format**
 
 Every error must contain an entry with the key `message` with a string