Skip to content

Commit 271b638

Browse files
committed
Update exception docs. Closes #2378.
1 parent d3b2302 commit 271b638

File tree

1 file changed

+11
-1
lines changed

1 file changed

+11
-1
lines changed

docs/api-guide/exceptions.md

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ The handled exceptions are:
1818

1919
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.
2020

21-
By default all error responses will include a key `detail` in the body of the response, but other keys may also be included.
21+
Most error responses will include a key `detail` in the body of the response.
2222

2323
For example, the following request:
2424

@@ -33,6 +33,16 @@ Might receive an error response indicating that the `DELETE` method is not allow
3333

3434
{"detail": "Method 'DELETE' not allowed."}
3535

36+
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 `NON_FIELD_ERRORS_KEY` setting.
37+
38+
Any example validation error might look like this:
39+
40+
HTTP/1.1 400 Bad Request
41+
Content-Type: application/json
42+
Content-Length: 94
43+
44+
{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}
45+
3646
## Custom exception handling
3747

3848
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.

0 commit comments

Comments
 (0)