śr., 24 cze 2026 o 19:16 Udo Steinbach via Boost <boost@lists.boost.org> napisał(a):
I’d like to raise a practical issue with the current direction of error-handling support. In my experience, existing models still leave too much uncertainty for both human and programmatic consumers of error information. I’m interested in whether a more general boost::exception-style mechanism could preserve richer diagnostic context without forcing users into narrow error codes or lossy secondary return values.
A general-purpose error-handling facility should preserve as much diagnostic information as possible, keep that information available for both human and programmatic consumers, and remain highly reliable itself.
An error message must enable the user of the program to identify the cause and investigate or fix it without further assistance, without experiments, without guesswork, and without help from third parties. It must also be usable programmatically.
To do that, it must identify four points: * The action triggered by the user or by an automated process in whose context the error occurred, including the consequences of incomplete execution, for example: “Not all mails could be retrieved; the missing ones are still on the server.” This is not the task of error handling itself, but of the top level, the user of the error-handling facility. * The cause, that is, the detected state, for example a full disk. * The object, such as a file path, device name, or similar, on which * the named operation failed: reading, writing, opening a window. Unless there are compelling reasons to the contrary, these points must have top priority; neglecting them is inexcusable.
It is not enough to simply produce text at the end; rather, the text must be part of the diagnosis that begins with the message. Ideally, it implicitly suggests a necessary or at least obvious course of action. For logging purposes, it must also allow later diagnosis. That is the task of the caller or an external instance, but the error must include the point of state recognition and the triggering operation. Taken together, these requirements mean that many participating levels and instances must collect information, and each must also have the opportunity to make use of it and act accordingly.
At the same time, no error-handling mechanism itself may become a source of errors; it must handle any runtime errors occurring within itself definitively. Errors that occur during error handling do not only lead to technical difficulties, but “errors during errors” can also conceal or distort the original error, or lead to unmanageable or otherwise unrecoverable follow-up errors. In my view, there is no alternative to making error handling itself free of errors. Existing solutions often do not take this requirement into account.
The widely unsatisfactory state of error messages shows that more is needed than yet another proposal. A good solution in boost could show what error messages should look like in the first place.
Hi Udo, What you describe sounds like an expectation of well designed programs and servers. Decent error reporting would be included in the program's architecture design and API design. It would require a shift from "this API is for returning best offers" to "this API is for returning offers or communicating why it was not possible to return best offers". You need to design how/if you will be translating error messages. Different error messages are reported to different users. For security or business-safety reasons you do not explain in detail what went wrong in the server to users. But you do communicate details to system maintenance teams via logs. But logging a lot of information is extremely costly, so you will end up balancing between the amount of log details and the storage consumption. This process of communicating errors becomes part of the business logic. I do not think a single library or a single "mechanism" for reporting errors would be enough to accomplish this. You have in Boost libraries that offer error types capable of setting and getting arbitrary pieces of information of arbitrary types (Boost.Exception), that allow integrating with other mechanisms of error handling from other libraries (Boost.Outcome), libraries that offer easy logging of different pieces of error-related data at different levels (Boost.LEAF) but all of them, and I think any other, are enough, and will not substitute for a server/program design that considers error reporting at every level. Regards, &rzej;