On Wed, Jun 24, 2026 at 1:16 PM Udo Steinbach via Boost < boost@lists.boost.org> wrote:
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.
Look at Boost LEAF, it lets you communicate arbitrary context with any error, with or without exceptions. You can associate arbitrary context with any failure, the error objects are communicated with type safety. At an error handling scope you have the option to format a user-friendly message based on the available data, or an automatic developer-friendly message, or to serialize everything into a machine-readable format (nlohmann and Boost.JSON are directly supported, but the serialization API is extensible.) Emil