Fix for issue #209: stop logging tracebacks for raised Responses.

[nejstastnejsistene]

As I commented in #209, the previous fix prevented handle_error from being called at all for Response exceptions. My fix instead removes log_error from handle_error so that errors are still handled appropriately, just without the tracebacks.

[nejstastnejsistene]

Oops, I spoke too soon, this broke one of the tests. Working on it...

[nejstastnejsistene]

Huh, the test that is failing (redirects don't add any headers, a197211) was added after the fix that removed the call to handle_error. My fix makes it so raised 3xx responses skip the resource getting step the same way as 2xx responses do. Tell me if you can think of any problems this would cause.

[pjz]

Hmm. I'm suspecting we need tests for this. Maybe a test that sets up a custom response and makes sure it gets used? Don't we have one of those already?

[nejstastnejsistene]

Tests are probably a good idea, but to make sure it gets used in what way?

I essentially made three changes:

• Remove an empty except Response block in handle_safely, reverting that part to the way it was about two weeks ago. This was preventing all explicitly raised responses from going through the error handling process at all. For what it's worth I think at least this should be fixed ASAP -- right now the latest version of aspen is sending absolutely nothing in response to 404 errors, for example.
• Remove the log_dammit(tb_1) call that I think was the main culprit of Issue tracebacks for raise Response are scary #209.
• Skip the the simplate delegation (the part that tries to render project_root/404.html, project_root/error.html, etc) step for 3xx responses like it already does for 2xx responses. This also fixes don't send Content-Type or Content-Length for 304 #211 because the additional headers were getting added in the simplate step. Upon reading the spec just now, maybe only 304 codes should skip the simplate step, because that is the only one that is forbidden from having a message body.

[nejstastnejsistene]

Also, as far as logging tracebacks go for #209, do you think it'd be better to still log the tracebacks for some status codes, such as 5xx errors for debugging, rather than getting rid of them completely?

[pjz]

That additiional 'except Response' was my attempt to not log tracebacks for 2xx and 3xx that happened to be raised - they're a kind of exceptional non-Exception. We should ideally log 5xx and maybe 4xx for debugging.. hrm, maybe just always log everything, with descending priorities: 5xx ERROR, 4xx WARNING, 3xx INFO, 2xx DEBUG ?
Something like:

log_level = [DEBUG, INFO, WARNING, ERROR][(response.code / 100) - 2]
logging.log(log_level, message)

304 does seem to be the singular exception that MUST NOT require a message body, so the code will have to reflect it one way or the other. So it should read:

if 200<= response.code <300 and response.code != 304:

Sound reasonable?

[nejstastnejsistene]

That sounds good, except right now aspen is using its own logging system which isn't fine-tuned enough to split up the logging like that. Perhaps a job for #157? The second part sounds perfect.

This commit logs only the 5xx tracebacks (with a TODO comment about switching to the logging module) and does the part with the 304 codes.