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. Udo -- Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E