On Sat, May 20, 2017 at 3:12 AM, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
When I perform an asynchronous HTTP operation that returns an error_code then I prefer that the error_code contains a unified response, i.e. an HTTP status code, a system error code (e.g. network problem), or an internal library error code.
I should have taken a bit more time before sending my reply - apologies. I am bursting with things to say about this subject as you can imagine so I will elaborate. Consider the following: f is a function r is an unspecified result of performing some calculation on m m is an HTTP response message r = f(m) If the calculation of r depends on the HTTP status, your proposal to shove the status into an error_code would require: r = f(m, ec) Where ec is an error_code. This introduces a problem, because now ec can contain things that are not HTTP status codes, such as boost::asio::error::connection_reset. f might not want or need to handle metadata about the TCP/IP connection or other errors that are not status codes. Now consider this: g is a function m' is an HTTP response message m' = g(m) This example uses a functional style where a message m is transformed by a function g into a new message. If we put the HTTP status in an error_code not part of m or m', the signature would look like this: pair<m', error_code> g(m, error_code); This signature imposes unnecessary burden on callers. It is also confusing. Does the error_code in the return value indicate that g can fail? I hope readers are convinced that HTTP requests and responses should be modeled as self-contained objects with all necessary fields prescribed by rfc7230, and that the HTTP status should be neither separate nor stored in an error_code.