What the 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.
