From 5ddd2d499fe2db97d4e1a0fd6be8195538a9f5f2 Mon Sep 17 00:00:00 2001
From: Christian Legnitto <LegNeato@users.noreply.github.com>
Date: Wed, 15 Jul 2020 21:09:19 -1000
Subject: [PATCH] Add heading for error handling and point to spec

Fixes https://github.com/graphql-rust/juniper/issues/695.
---
 docs/book/content/types/objects/error_handling.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/docs/book/content/types/objects/error_handling.md b/docs/book/content/types/objects/error_handling.md
index d42d2daf..d80201b7 100644
--- a/docs/book/content/types/objects/error_handling.md
+++ b/docs/book/content/types/objects/error_handling.md
@@ -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
 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
 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
@@ -124,6 +129,7 @@ following would be returned:
 }
 ```
 
+
 ### Structured errors
 
 Sometimes it is desirable to return additional structured error information