pon., 6 lip 2026 o 17:40 Jamie Allsop via Boost <boost@lists.boost.org> napisał(a):
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.
Any idea where this misconception may be coming from?
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).
I do not find it helpful to mix the notion of postcondition failures (this is what I understand errors to be) and being on the hot path. For operations on streams it makes sense to promise nothing, as the implementer is not in control of the environment. But at the level of algorithms like when_any the documentation ( https://develop.capy.cpp.al/capy/reference/boost/capy/when_any-07.html#_desc... ) starts to assign the interpretation to these "just status fields" as being a failure and error. Looks like the library seems confused as to whether to treat non-zero error_codes as errors. And there are ways to handle postcondition violations on hot paths, like https://www.boost.org/doc/libs/latest/libs/outcome/doc/html/tutorial/essenti... Regards, &rzej; _______________________________________________
Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/QR52OMNF...