UnWrap HttpErrors in pop middleware and return them.

[lumost]

The pop transaction middleware wraps all handlers in a connection.Transaction, which in turn wraps any errors the handler emits. The default ErrorHandler will then handle the error as a 500 and will not be able to mirror the requested status from a call such as c.Error(401, err)

[markbates]

Thinking about this, I feel like it should be moved to where the error handling is done globally, so everything benefits, not just this middleware.

Thoughts?

[lumost]

I like the idea; one potential issue is that we will always swallow the error from the middleware, which could be a problem for folks rolling in their own middlewares. Do you think it would be worthwhile to create an additional MiddlewareError type to allow middlewares to override the HTTPError?

side note - I'll take a look at the build issue.

[lumost]

I did some digging on potential ways of handling the case where different middleware's in the chain would want to alter the final response. By far the simplest solution is to expose the HTTPError type at the package level and allow middlewares to return it if they need to alter the error response, optionally these middlewares can embed the original HTTPError in the msg of the response or add additional field to the error depending on the use case.

I've set it up as you suggested and will check whether the root error is a buffalo.HTTPError for all handlers and if it is we will use that status code.

[markbates]

This looks good! Thanks!