Also use consistent error verbs

Saw "throw" / "raise" / "occur" / "encounter" - most dominant verb is "raise" so standardizing that.

Author: leebyron

spec/Section 3 -- Type System.md

@@ -1514,10 +1514,10 @@ type of an Object or Interface field.
 **Input Coercion**
 
 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 thrown. In either
+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 thrown.
+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
@@ -1526,7 +1526,7 @@ is constructed with the following rules:
 * If no value is provided for a defined input object field and that field
   definition provides a default value, the default value should be used. If no
   default value is provided and the input object field's type is non-null, an
-  error should be thrown. Otherwise, if the field is not required, then no entry
+  error should be raised. Otherwise, if the field is not required, then no entry
   is added to the coerced unordered map.
 
 * If the value {null} was provided for an input object field, and the field's
@@ -1540,7 +1540,7 @@ is constructed with the following rules:
 
 * If a variable is provided for an input object field, the runtime value of that
   variable must be used. If the runtime value is {null} and the field type
-  is non-null, a field error must be thrown. If no runtime value is provided,
+  is non-null, a field error must be raised. If no runtime value is provided,
   the variable definition's default value should be used. If the variable
   definition does not provide a default value, the input object field
   definition's default value should be used.

spec/Section 5 -- Validation.md

@@ -2013,4 +2013,4 @@ query booleanArgQueryWithDefault($booleanArg: Boolean = true) {
 ```
 
 Note: The value {null} could still be provided to such a variable at runtime.
-A non-null argument must produce a field error if provided a {null} value.
+A non-null argument must raise a field error if provided a {null} value.

spec/Section 6 -- Execution.md

@@ -41,10 +41,10 @@ GetOperation(document, operationName):
   * If {operationName} is {null}:
     * If {document} contains exactly one operation.
       * Return the Operation contained in the {document}.
-    * Otherwise produce a request error requiring {operationName}.
+    * Otherwise raise a request error requiring {operationName}.
   * Otherwise:
     * Let {operation} be the Operation named {operationName} in {document}.
-    * If {operation} was not found, produce a request error.
+    * If {operation} was not found, raise a request error.
     * Return {operation}.
 
 
@@ -92,14 +92,14 @@ CoerceVariableValues(schema, operation, variableValues):
       * Add an entry to {coercedValues} named {variableName} with the
         value {defaultValue}.
     * Otherwise if {variableType} is a Non-Nullable type, and either {hasValue}
-      is not {true} or {value} is {null}, throw a request error.
+      is not {true} or {value} is {null}, raise a request error.
     * Otherwise if {hasValue} is true:
       * If {value} is {null}:
         * Add an entry to {coercedValues} named {variableName} with the
           value {null}.
       * Otherwise:
         * If {value} cannot be coerced according to the input coercion
-          rules of {variableType}, throw a request error.
+          rules of {variableType}, raise a request error.
         * Let {coercedValue} be the result of coercing {value} according to the
           input coercion rules of {variableType}.
         * Add an entry to {coercedValues} named {variableName} with the
@@ -253,7 +253,7 @@ CreateSourceEventStream(subscription, schema, variableValues, initialValue):
   * Let {selectionSet} be the top level Selection Set in {subscription}.
   * Let {groupedFieldSet} be the result of
     {CollectFields(subscriptionType, selectionSet, variableValues)}.
-  * If {groupedFieldSet} does not have exactly one entry, throw a request error.
+  * If {groupedFieldSet} does not have exactly one entry, raise a request error.
   * Let {fields} be the value of the first entry in {groupedFieldSet}.
   * Let {fieldName} be the name of the first entry in {fields}.
     Note: This value is unaffected if an alias is used.
@@ -340,7 +340,7 @@ is explained in greater detail in the Field Collection section below.
 
 **Errors and Non-Null Fields**
 
-If during {ExecuteSelectionSet()} a field with a non-null {fieldType} throws a
+If during {ExecuteSelectionSet()} a field with a non-null {fieldType} raises a
 field error then that error must propagate to this entire selection set, either
 resolving to {null} if allowed or further propagated to a parent field.
 
@@ -590,7 +590,7 @@ CoerceArgumentValues(objectType, field, variableValues):
       * Add an entry to {coercedValues} named {argumentName} with the
         value {defaultValue}.
     * Otherwise if {argumentType} is a Non-Nullable type, and either {hasValue}
-      is not {true} or {value} is {null}, throw a field error.
+      is not {true} or {value} is {null}, raise a field error.
     * Otherwise if {hasValue} is true:
       * If {value} is {null}:
         * Add an entry to {coercedValues} named {argumentName} with the
@@ -600,7 +600,7 @@ CoerceArgumentValues(objectType, field, variableValues):
           value {value}.
       * Otherwise:
         * If {value} cannot be coerced according to the input coercion
-            rules of {argumentType}, throw a field error.
+            rules of {argumentType}, raise a field error.
         * Let {coercedValue} be the result of coercing {value} according to the
           input coercion rules of {argumentType}.
         * Add an entry to {coercedValues} named {argumentName} with the
@@ -645,12 +645,12 @@ CompleteValue(fieldType, fields, result, variableValues):
     * Let {innerType} be the inner type of {fieldType}.
     * Let {completedResult} be the result of calling
       {CompleteValue(innerType, fields, result, variableValues)}.
-    * If {completedResult} is {null}, throw a field error.
+    * If {completedResult} is {null}, raise a field error.
     * Return {completedResult}.
   * If {result} is {null} (or another internal value similar to {null} such as
     {undefined}), return {null}.
   * If {fieldType} is a List type:
-    * If {result} is not a collection of values, throw a field error.
+    * If {result} is not a collection of values, raise a field error.
     * Let {innerType} be the inner type of {fieldType}.
     * Return a list where each list item is the result of calling
       {CompleteValue(innerType, fields, resultItem, variableValues)}, where
@@ -716,13 +716,13 @@ MergeSelectionSets(fields):
 
 ### Errors and Non-Nullability
 
-If an error is thrown while resolving a field, it should be treated as though
+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.
 
 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
-field is of a `Non-Null` type, then a field error is thrown. The
+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

spec/Section 7 -- Response.md

@@ -2,16 +2,15 @@
 
 When a GraphQL service receives a request, it must return a well-formed
 response. The service's response describes the result of executing the requested
-operation if successful, and describes any errors encountered during the
-request.
+operation if successful, and describes any errors raised during the request.
 
-A response may contain both a partial response as well as encountered errors in
-the case that a field error occurred on a field which was replaced with {null}.
+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 that occur during a GraphQL request are termed "request errors."
-Request errors are not limited to errors that occur during execution of the
+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.
@@ -20,9 +19,9 @@ contain sufficient information to indicate uniquely which operation to execute.
 
 A response to a GraphQL request must be a map.
 
-If the request encountered any errors, the response map must contain an
+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 encountering any errors, this entry
+section. If the operation completed without raising any errors, this entry
 must not be present.
 
 If the request included execution, the response map must contain an entry
@@ -50,10 +49,10 @@ requested operation. If the operation was a query, this output will be an
 object of the schema's query root type; if the operation was a mutation, this
 output will be an object of the schema's mutation root type.
 
-If an error was encountered before execution begins, the `data` entry should
+If an error was raised before execution begins, the `data` entry should
 not be present in the result.
 
-If an error was encountered during the execution that prevented a valid
+If an error was raised during the execution that prevented a valid
 response, the `data` entry in the response should be `null`.
 
 
@@ -62,17 +61,17 @@ response, the `data` entry in the response should be `null`.
 The `errors` entry in the response is a non-empty list of errors, where each
 error is a map.
 
-If no errors were encountered during the request, the `errors` entry should
+If no errors were raised during the request, the `errors` entry should
 not be present in the result.
 
 If the `data` entry in the response is not present, the `errors`
 entry in the response must not be empty. It must contain at least one error.
 The errors it contains should indicate why no data was able to be returned.
 
 If the `data` entry in the response is present (including if it is the value
-{null}), the `errors` entry in the response may contain any errors that
-occurred during execution. If errors occurred during execution, it should
-contain those errors.
+{null}), the `errors` entry in the response may contain any field errors that
+were raised during execution. If field errors were raised during execution, it
+should contain those errors.
 
 **Error result format**
 
@@ -149,7 +148,7 @@ The response might look like:
 If the field which experienced an error was declared as `Non-Null`, the `null`
 result will bubble up to the next nullable field. In that case, the `path`
 for the error should include the full path to the result field where the error
-occurred, even if that field is not present in the response.
+was raised, even if that field is not present in the response.
 
 For example, if the `name` field from above had declared a `Non-Null` return
 type in the schema, the result would look different but the error reported would