DRF overwrites Django's Http404 details message in favour of its own #7794
Replies: 7 comments 2 replies
-
Okay. One thing we’d also need to be aware of is that custom messages wouldn’t get our built-in translations. What’s Django’s default message when raising Http404? |
Beta Was this translation helpful? Give feedback.
-
It seems the default behavior when raising Http404 with no arguments is to omit the 'info' part. And here's one with the details: This is the code, simply extends the base Exception:
|
Beta Was this translation helpful? Give feedback.
-
Ran into this problem where we were implementing a custom exception handler and were using Something like the following helped for the time being:
The The default message for the django |
Beta Was this translation helpful? Give feedback.
-
Ran into this problem. Googled and found this ticket. So subscribed to get updates on how to overcome this as well |
Beta Was this translation helpful? Give feedback.
-
@harisibrahimkv can you share your custom exception handler code? I think I may have to adopt the same as a workaround until DRF has a solution for this |
Beta Was this translation helpful? Give feedback.
-
@simkimsia My custom exception handler code is the same that I have pasted in my comment above. The specific
|
Beta Was this translation helpful? Give feedback.
-
For those who come here and just want this to be working at their Code (like me): Just replace |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
When raising Http404 (django.http.Http404), with a message, e.g:
raise Http404('My custom details')
inside of a function decorated with DRF's api_view (or any class based view, e.g. generics.ListApiView), DRF ignores the details and overwrites them with its own message. The cause are these lines of code in views.py:
As you can see, in case of Http404, exc is overriden without any arguments it had (the details) being passed. This can result in a headache when other libraries throw Http404 and you use their functionalities in your api views.
In particular, I was using social-app-django's psa decorator) which in one case throws Http404 with a very important message:
The raised error I got was simply 'Not found' instead of 'Backend not found', which led me to mistakenly believe I've messed something up in my urls. As it stands, other libraries used in conjunction with DRF will always get their 404 details 'swallowed'.
Steps to reproduce
raise Http404('My details') inside of a DRF class-based view or function decorated with api_view
Expected behavior
404 error with message 'My details' is returned
Actual behavior
404 error with message 'Not found' is returned
Beta Was this translation helpful? Give feedback.
All reactions