yume/juniper
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add heading for error handling and point to spec

Browse source 
Fixes https://github.com/graphql-rust/juniper/issues/695.
This commit is contained in:
Christian Legnitto 2020-07-15 21:09:19 -10:00 • committed by GitHub
parent 3616e36ece
commit 5ddd2d499f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 0 deletions

6
docs/book/content/types/objects/error_handling.md
View file

@ -62,6 +62,11 @@ type all fields must return. By using the `?` operator or `try!` macro, any type
that implements the `Display` trait - which are most of the error types out that implements the `Display` trait - which are most of the error types out
there - those errors are automatically converted into `FieldError`. there - those errors are automatically converted into `FieldError`.
## Error payloads, `null`, and partial errors
Juniper's error behavior conforms to the [GraphQL specification](https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability).
When a field returns an error, the field's result is replaced by `null`, an When a field returns an error, the field's result is replaced by `null`, an
additional `errors` object is created at the top level of the response, and the additional `errors` object is created at the top level of the response, and the
execution is resumed. For example, with the previous example and the following execution is resumed. For example, with the previous example and the following
@ -124,6 +129,7 @@ following would be returned:
} }
``` ```
### Structured errors ### Structured errors
Sometimes it is desirable to return additional structured error information Sometimes it is desirable to return additional structured error information