Stacktraces caused by errors in response middleware look different than other errors
|Reported by:||eibaan||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
I accidentally returned a number from a view. Obviously an error, but instead of the usual nice debug page, a black-on-white stacktrace is all that is returned. I'm using the development server and the SVN trunk version if that matters.
Traceback (most recent call last): File ".../python2.5/site-packages/django/core/servers/basehttp.py", line 277, in run self.result = application(self.environ, self.start_response) File ".../python2.5/site-packages/django/core/servers/basehttp.py", line 631, in __call__ return self.application(environ, start_response) File ".../python2.5/site-packages/django/core/handlers/wsgi.py", line 209, in __call__ response = middleware_method(request, response) File ".../python2.5/site-packages/django/middleware/common.py", line 90, in process_response if response.status_code == 404: AttributeError: 'int' object has no attribute 'status_code'
It looks like that the request, view and exception middleware is protected by the usual technical_500_response handler (see base.py, BaseHandler.get_response()) but not the response middleware (see wsgi.py, WSGIHandler.call()) Is there a reason for this difference? Why can't the base handler also apply the response middleware (just before the return in line 101 in base.py)? Both modpython.py and wsgi.py seem to use the same chunk of code here which could moved to base.py.
Change History (3)
Changed 9 years ago by Jan Rademaker <j.rademaker@…>
comment:1 Changed 9 years ago by Jan Rademaker <j.rademaker@…>
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset