_pre_response_handlers should be called in Exception cases as well

[soundofjw]

This may be solved more simply in a true pale solution of #13.

Our current issue is that ArgumentErrors call API.UnprocessableEntity (HTTP:422) which bypasses the _pre_response_handlers. This may be the desired behavior, but it leaves us unable to send a CORs header when there are argument errors.

[soundofjw]

@rknLA @npbee I'd love your thoughts here :)

[rknLA]

Yeah, so looking at the _pre_response_handlers thing, a couple of thoughts come to mind:

• First, assuming this is the right way to solve the problem, I'm not a huge fan of the name, since technically everything is "pre-response". If we wind up keeping the functionality, I would suggest calling it _after_render_handlers or _post_render_handlers or something along those lines, since it's more specific.
• Second, is this the right way to solve this problem? I'm all for figuring out how to elegantly keep this if it's clear that it has uses beyond just CORS, but my gut reaction is that it might cause more headaches in a general state -- It confuses some of the structure and process. Adding a step to the execution pipeline outside of the try/except seems like it will better enable people to shoot themselves in the foot, and seems like it enables/encourages monkey-patching beyond what should be necessary. I completely understand why you put it outside of the try/except block, but it still makes me a bit uneasy.

CORS is a pretty specific problem, and imho, probably common enough in HTTP APIs to have CORS-specific functionality, rather than adding more generalization.