You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using this library for our project and it is amazing.
The only thing we have noticed (we are using structlog + django-structlog + structlog-sentry), the unhandled exceptions are not properly propagated and therefore handled (some libraries are using process_exception inside middleware to "add" something useful or to log something outside.
Currently when unhandled exception is happening, it is automatically "wrapped" into 500 response and returned and therefore no standard Django flow is running to "process" this exception, meaning all middlewares and additional libraries become useless in this case.
Instead it would be great to "propagate" the unhandled exception through all the middlewares and then properly process it inside custom 404 or 500 handlers.
What do you think? Is it possible to implement somehow? Just asking... as I dug into the codebase and and could not find easy route. Unfortunately not all libraries are relying on the signal got_request_exception.
Best regards,
Sergei
The text was updated successfully, but these errors were encountered:
Honestly, the idea is interesting especially that it allows the middleware to also process the exception. However, this is an exception handler for DRF specifically.
Still, here's how you can work around the issue you described:
create a custom exception handler
fromdrf_standardized_errors.handlerimportExceptionHandlerclassCustomExceptionHandler(ExceptionHandler):
defshould_not_handle(self, exc: Exception) ->bool:
is_drf_exception=isinstance(exc, APIException)
ifnotis_drf_exception:
# attach the context to the exception so we can use it later in the django's handler500.# Also, serves as a way to identify exceptions that came from a drf viewexc.drf_handler_context=self.context# handle drf exceptions only. This restores the behavior of the original drf exception handler# and propagates any other exceptionsreturnnotis_drf_exception
then update the settings DRF_STANDARDIZED_ERRORS = {"EXCEPTION_HANDLER_CLASS": "path.to.CustomExceptionHandler"}
define the custom handler500
importsysfromdjango.httpimportJsonResponsefromdjango.views.defaultsimportserver_errorfromsomewhereimportCustomExceptionHandlerdeferror_handler(request):
_, exc, __=sys.exc_info()
ifcontext:=getattr(exc, "drf_handler_context", None):
handler=CustomExceptionHandler(exc, context)
exc=handler.convert_unhandled_exceptions(exc)
data=handler.format_exception(exc)
returnJsonResponse(data, status=500)
else:
# for exceptions raised in a non-drf view, use the default django error handlerreturnserver_error(request)
then set handler500 = "path.to.error_handler" in your urls.py
Hi dear maintainer,
We are using this library for our project and it is amazing.
The only thing we have noticed (we are using
structlog
+django-structlog
+structlog-sentry
), the unhandled exceptions are not properly propagated and therefore handled (some libraries are usingprocess_exception
inside middleware to "add" something useful or to log something outside.Currently when unhandled exception is happening, it is automatically "wrapped" into 500 response and returned and therefore no standard Django flow is running to "process" this exception, meaning all middlewares and additional libraries become useless in this case.
Instead it would be great to "propagate" the unhandled exception through all the middlewares and then properly process it inside custom 404 or 500 handlers.
What do you think? Is it possible to implement somehow? Just asking... as I dug into the codebase and and could not find easy route. Unfortunately not all libraries are relying on the signal
got_request_exception
.Best regards,
Sergei
The text was updated successfully, but these errors were encountered: