Re: What an error message must do

śr., 24 cze 2026 o 19:16 Udo Steinbach via Boost <[email protected]>
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;
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/TEXZPZJFBTKTSAOT3QT3FT3JXH57HVCB/