Hello boost people, I am not using boost::exception. I have my own solution, a beginner-style base class with a unique_ptr to itself and derivations for every information, since 10 years before boost::exception came out. I am thinking about to rebuild it as a mix of boost::exception's heterogeneous container and my class' reliability in any situation. Now I have the idea, that someone other may interested to publish something like that as part of boost, even the boost::exception authors? I'd love to contribute, but my working style and libraries do not fit boost conventions, so I would end up maintaining two identical libraries. But I'd be happy to help if someone takes it forward. Thesis 1: During error handling, no errors may occur. An error object must not be overwritten by a secondary failure due to random allocation success. Therefore noexcept for almost all functions is mandatory. Without it, you either lose the original error (masked) or std::terminate() the program. It is better to drop info-objects instead. My classes have passed all such tests --- they only fail when the program is already uncontrollable (e.g., no memory left even for a throw itself). Anyway, my class proves that runtime error handling and presenting can be rock-solid stable with pure C++. Thesis 2: Therefore we need minimalistic structures, exception free memory (new (std::nothrow)) and functions to copy objects without exceptions, static_assert(std::is_nothrow_..._v) and other little neat things. Whatever can throw there must be a catched, nothing escapes boost::exception2 (except few output functions). Thesis 3: std::expected, boost::leaf & Co. pursue a different goal than error handling. A error is a rare event during program lifetime. We account for it, but don't expect it. In contrast, error-as-return-value is an expected value handled locally. And: not every technical issue is a error from user's perspective, e.g. file-not-found. Only in rare cases one may return something like result<T,boost::exception>, e.g. the caller needs the data or message without catching an exception. Classes like boost::exception or mine are the only C++-idiomatic way to handle errors. Thesis 4: std::exception is less then useless. It does not transport enough information to generate useful text. Instead throwing them hinders error handling, I have to catch and convert them everywhere. A small contraindication: An empty boost::exception has no distinguishable text. If my thrown TFileError is empty, it has "A file error...". But that's irrelevant, one need external help to produce a no memory condition at throw. I see errors with user's eyes, it's about generating reliable diagnostic text. But this doesn't affect the structures or query capabilities. What do you think? Looking forward to your thoughts! says Udo sitting in rainy Oldenburg, Germany -- Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E