|
| 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. |
0 commit comments