If a view raises a SystemExit exception, the BaseHandler should allow the exception to propagate up the stack (I think)
|Reported by:||Owned by:||nobody|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
BaseHandler does at present, is this:
except SystemExit: pass # See http://code.djangoproject.com/ticket/1023
What I expect it to do is this:
except SystemExit: raise
I found this to be a problem when testing. I, at one point, placed a "
raise SystemExit()" in one of my views, for debugging purposes. Later on, (well after forgetting about that "
raise SystemExit()" I placed earlier) I was having a test failure, like this:
... File "/usr/local/lib/python2.5/site-packages/django/test/client.py", line 44, in __call__ response = middleware_method(request, response) File "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/middleware.py", line 87, in process_response patch_vary_headers(response, ('Cookie',)) File "/usr/local/lib/python2.5/site-packages/django/utils/cache.py", line 105, in patch_vary_headers if response.has_header('Vary'): AttributeError: 'NoneType' object has no attribute 'has_header'
Although the problem was a bit more clear once I had a look at the view that was under test (duh), the problem was not at all clear from the failing test's error message. The raised
SystemExit exception should have caused the test to halt execution, however, since the
BaseHandler essentially ignores the
SystemExit exception, the
BaseHandler.get_response() method ends up returning
None (implicitly, because nothing else is returned).
I suspect this could cause pain elsewhere (if only when debugging); it just doesn't seem right to "
pass" on such an exception
Browsing over #1023, it doesn't look as if there was ever a clear answer as to why using
pass was chosen over using
raise, to deal with this special-case exception.