Skip to content

Commit 72fc4ec

Browse files
committed
add new FAQ page in the docs
1 parent bb93acc commit 72fc4ec

File tree

2 files changed

+46
-0
lines changed

2 files changed

+46
-0
lines changed

docs/faq.md

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# FAQs
2+
3+
## Standardized errors are not shown in local development
4+
5+
By default, standardized error responses when `DEBUG=True` for unhandled exceptions are disabled.
6+
That is to allow you to get more information out of the traceback. You can enable standardized errors
7+
instead with:
8+
9+
```python
10+
DRF_STANDARDIZED_ERRORS = {"ENABLE_IN_DEBUG_FOR_UNHANDLED_EXCEPTIONS": True}
11+
```
12+
13+
14+
## Some exceptions are not converted to the standardized format
15+
16+
This package is a DRF exception handler, so it only standardizes errors that reach a DRF API view.
17+
That means it cannot handle errors that happen at the middleware level for example. To handle those
18+
as well, you can customize the necessary [django error views](https://docs.djangoproject.com/en/dev/topics/http/views/#customizing-error-views).
19+
You can find more about that in [this issue](https://github.com/ghazi-git/drf-standardized-errors/issues/44).
20+
21+
22+
## I want to let exceptions propagate up the middleware stack
23+
24+
This might be needed when code written in middleware adds custom logic based on raised exceptions
25+
(either by you or by a third party package). In that case, it is possible to allow the exception
26+
to pass through the DRF exception handler and later convert it to the corresponding error response
27+
in django error views. You can check [this issue](https://github.com/ghazi-git/drf-standardized-errors/issues/91#issuecomment-2397956441) for sample code.
28+
29+
30+
## How can I add extra details about the exception in the error response
31+
32+
This can be done using a custom exception along with a custom exception formatter. You can find sample
33+
code in [this issue](https://github.com/ghazi-git/drf-standardized-errors/issues/95#issuecomment-2661633736).
34+
Note that this does not work with `ValidationError`s or its subclasses raised in a serializer. That's
35+
because DRF creates new `ValidationError` instances when they are raised. See
36+
[here](https://github.com/encode/django-rest-framework/blob/f30c0e2eedda410a7e6a0d1b351377a9084361b4/rest_framework/serializers.py#L221-L231)
37+
and [here](https://github.com/encode/django-rest-framework/blob/f30c0e2eedda410a7e6a0d1b351377a9084361b4/rest_framework/serializers.py#L443-L448).
38+
39+
40+
## How to integrate this package with djangorestframework-camel-case
41+
42+
You can check this [issue](https://github.com/ghazi-git/drf-standardized-errors/issues/59#issuecomment-1889826918)
43+
for a possible solution. Still, `djangorestframework-camel-case` is built to work specifically with
44+
the default exception handler from DRF. It assumes that field names are the keys in the returned dict.
45+
So, that does not work well with this package.

docs/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,7 @@ quickstart.md
88
settings.md
99
error_response.md
1010
customization.md
11+
faq.md
1112
gotchas.md
1213
openapi.md
1314
openapi_sample_description.md

0 commit comments

Comments
 (0)