Changes between Initial Version and Version 1 of Ticket #30858
- Timestamp:
- Oct 8, 2019, 2:32:52 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #30858 – Description
initial v1 9 9 ''Whenever your code raises an unhandled exception, or your view returns a response with a status code 500'' 10 10 11 The nuance is perhaps small, but we had been operating under the assumption that views returning a response with status_code=500 would be 'silent' and not generate emails as they are internal server errors, but have already been correctly and safely handled by our code but we still want to send the client a 500to inform them that the response could not be completed as expected. We assumed based on that line that emails would ONLY be sent as a result of unhandled exceptions.11 The nuance is perhaps small, but we had been operating under the assumption that views returning a response with status_code=500 would be 'silent' and not generate emails as they are internal server errors, but have already been correctly and safely handled by our code yet we still want to send the client a 500 error to inform them that the response could not be completed as expected. We assumed based on that line that emails would ONLY be sent as a result of unhandled exceptions. 12 12 13 13 It may be worth expanding on the error handling to allow users to return 'safe' 500 responses that will not be logged, and in fact Django does check for the _has_been_logged property already before logging the response, which we can set in our code already so perhaps just exposing that to the documentation in a little note would be useful to people who want to send 500 responses without sending emails might be sufficient.