Exception and Error Handlers break content type negotiation

It would be nice to actually have the Exception and Error Routes be treated the same as all other types or Route objects. Instead what happens is the minute there's an exception, all of the accept() routine functionality is completely ignored and a call is made to these handlers that just spits that content out as is without any regard to the Accept header. This breaks parsers that are expecting valid content responses.

On top of this issue, if you return an empty string to try to at least prevent the parsing issues without giving any detail to the cause, it still breaks. It appears that the Request object is doing lazy comparisons with what was returned from the Exception handler and if it's an empty value, it assumes that the handler failed and then rethrows the exception.

This is basically a deal breaker since my choice is to not handle exceptions and have the API break entirely, or return non valid content results and have the API parsers break on the client side. Both completely unacceptable.

Start by tracing the Exception and Error Routes, the accept() routine, and the Request object behavior described in the issue. Reproduce an exception with different Accept headers and with an empty handler response. Done means exception responses undergo content negotiation and an empty response does not cause the original exception to be rethrown.