Update documentation

1 files changed, 9 insertions, 1 deletions

diff --git a/api-guide/exceptions/index.html b/api-guide/exceptions/index.html
index a0734a14..f9403f1d 100644
--- a/api-guide/exceptions/index.html
+++ b/api-guide/exceptions/index.html
@@ -442,7 +442,7 @@
 <li>Django's <code>PermissionDenied</code> exception.</li>
 </ul>
 <p>In each case, REST framework will return a response with an appropriate status code and content-type.  The body of the response will include any additional details regarding the nature of the error.</p>
-<p>By default all error responses will include a key <code>detail</code> in the body of the response, but other keys may also be included.</p>
+<p>Most error responses will include a key <code>detail</code> in the body of the response.</p>
 <p>For example, the following request:</p>
 <pre><code>DELETE http://api.example.com/foo/bar HTTP/1.1
 Accept: application/json
@@ -454,6 +454,14 @@ Content-Length: 42
 
 {"detail": "Method 'DELETE' not allowed."}
 </code></pre>
+<p>Validation errors are handled slightly differently, and will include the field names as the keys in the response. If the validation error was not specific to a particular field then it will use the "non_field_errors" key, or whatever string value has been set for the <code>NON_FIELD_ERRORS_KEY</code> setting.</p>
+<p>Any example validation error might look like this:</p>
+<pre><code>HTTP/1.1 400 Bad Request
+Content-Type: application/json
+Content-Length: 94
+
+{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}
+</code></pre>
 <h2 id="custom-exception-handling">Custom exception handling</h2>
 <p>You can implement custom exception handling by creating a handler function that converts exceptions raised in your API views into response objects.  This allows you to control the style of error responses used by your API.</p>
 <p>The function must take a single argument, which is the exception to be handled, and should either return a <code>Response</code> object, or return <code>None</code> if the exception cannot be handled.  If the handler returns <code>None</code> then the exception will be re-raised and Django will return a standard HTTP 500 'server error' response.</p>