On 06/07/2026 15:03, Vinnie Falco via Boost wrote:
On Sun, Jul 5, 2026 at 1:48 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
[...]
The library doesn't give me a clear picture on how it handles and how I
should handle the non-clear-sky situations. For things that represent obvious disappointments -- broken connection, problems on the wire, not enough memory to process a request -- it sometimes returns an error_code and sometimes throws an exception. It looks like the division is: * for things happening on the wire, or in the system's native part of the I/O implementation, use error_code * for problems with resources in the implementation of the library throw exceptions.
Right, and isn't this the guidance from the Standard?
But then also, the library returns error_codes for situations that are not
errors by any measure: for situations that I desire: * Successfully receiving full stream content. * Stopping the running process upon my request.
Who said they are supposed to be "errors"? `error_code` is just a label. You are attaching semantic significance to the type name. The contract of the algorithm is preeminent. And every algorithm in Capy and Corosio has documentation on what to expect. If something is missing, please open an issue - you know we will attend to it.
There is nothing wrong with error_code returning something which does not indicate an "error" in the strict sense. boost::error_code even has a mechanism to broaden the API past what the Standard offers, to know which codes are failures and which are not.
Just to note here that this is an important observation and one I'd like to reiterate. "error codes are for errors" is a common misconception in this space. Sometimes in fact an "error" might be on a hot path scenario. This is one reason why reasoning about a separate error channel is often the wrong mental model to adopt. Instead "errors" are really just alternative control flow paths, and as I said, sometimes the hot path. It's one reason why error codes are preferred as they don't force an opinion on the impact, handling, and importantly cost, of a "non-success" path (sometimes expected).