Apologies for the formatting - I'm fighting with Gmail which does not understand how mailing lists work... On 06/07/2026 23:20, Andrzej Krzemienski wrote:
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?
I think we can't shy away from the fact that we named it "error_code" when it probably made sense to go with something like "status_code" or "result_code" though to be fair I think that ship has sailed. This still trips me up when I look at code and see "error_code". It's unfortunate but it is what it is. As I recall (way back) there was some conversation around this but we didn't have the wealth of experience with alternative approaches to actual errors to make it easier to reason about non-error errors without getting drawn into sideways conversations. When we were still hoping to get networking into C++ for 20 there were a lot of crossed conversations about error codes and error channels that were not helped by the naming (and from our discussion solving different problems).
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.
I sympathise with this observation and I would say the main issue here is that in many cases error codes might not be an error in the context of postcondition failures (which in past I would have thought often were the purview of exceptions - I can't meet my postconditions so I can't complete...exception). I see that differently as my postcondition is that I can complete, but the result of completion might be that (for example) that I could not read any more bytes from a stream (because there aren't any). This comes back to naming then, and how we reason about this. I think you are right to point out that "when_any" is an example of how what I just said can't really hold in a context where we decide that the notion of a "preferred success", or "expected success outcome" is the criteria to be measured. I'd argue though that that just means that any generalised facility that relies on a simple model which assumes an error code only has one "success" result can only be applied where that assumption is true. If it doesn't then don't use the facility or, perform some kind of translation to achieve that behaviour for your use case allowing the utility to be of value.
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...
Thanks for sharing this. I've never used it but I'll be sure to familiarise myself with it should I need it in the future. However, you highlight a an important point here and that is that in the cases I am thinking of I'm saying that the error code (poorly named as it is in some contexts) represents, not a violation of postconditions, but rather one of a number of possible outcomes that represents completion of a given operation. One that is to be expected under certain circumstances, and in some cases, possibly very frequent and likely on the hot path. In other words the error code tells you how the operation completes, not if it completed. At some higher level of abstraction we can easily reason that some kinds of completion violates higher level postconditions and that's an error. Which is all to say I think everything you said is pretty spot on but unfortunately error code is probably poorly named and that simply creates confusion. Not all "errors" are failures in a nutshell. Best wishes, Jamie
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...