redding/sanford — pull request #37 by jcredding (2013-01-23 14:36:49+00:00)
Title: Configure error handling as a block on a service host

This changes error handling to be a block configured on a service
host instead of as a exception handler class. This is a simpler
interface and should be easier to work with. The block is passed
an exception and as much information as possible for the request.
It can then decide to generate it's own response, by returning a
protocol response or an integer/symbol. If a response is not
generated by the configured error block, then Sanford will
generate it's own response.

@kellyredding - This is still a WIP (missing more tests) but this is the implementation for the reworked error handling. There is a special case that I want to point out and make sure how I handled it makes sense.

The basic question is: if a configured error block raises an exception while trying to handle a previous exception, how should Sanford behave? With this PR, Sanford will use the second exception (not the original one) and build a response for it. It will also be sure to log this exception. In my opinion, this is less confusing and does less "hiding" of exceptions. For example, if I instead go off the first exception, a lot of my tests still pass, because they rely on Sanford's standard behavior. I'm not sure one way is that much better than the other, but this made the most sense to me. Thanks.