This could be a nice addition, but (as far as I can see) it's completely and easily implementable on top of the proposed design.
Certainly. Now, reassembling the original thought: This kind of interface could be exploited by the library to implement the 'throw e(a,b,c)' case with (almost) no overhead compared to the traditional approach - that is, without having to use a custom allocator.
I am not sure what you mean by that, since data added to exceptions after the throw has to come from the heap. If you mean that at least data passed to boost::exception at the time of the throw could be embedded into the exception object instead of using separate storage from the heap, that is also not possible (in general) because of the no-throw copy semantics required by the standard. So my question is what do you call "the traditional" approach? Say you want to transport a std::string into an exception. You can't just have: struct my_exception { std::string s_; //may throw on copy! }; What you need is something like: struct my_exception { shared_ptr<std::string> s_; }; This is pretty much what Boost Exception does, except that it's done generically (the current implementation has a bit more overhead because it uses std::map, but this is purely an implementation detail that can be optimized if it ever shows up in someone's profile.) Emil Dotchevski