Are you sure the reserve() will reduce the risk significantly? Note that boost::exception_ptr itself also allocates memory, not to mention the onNotify functions themselves, assuming they aren't trivial they could be allocating things as well.
If onNotify throws due to lack of memory then it is just as if it threw anything else. (Except for slightly larger risk of failure in throwing MultiException due to lack of memory for the exception itself.) boost::current_exception and boost::exception_ptr operations do are declared to not throw. I was surprised that boost::current_exception does not throw even std::bad_alloc but documentation says that. So in case of lack of memory it returns exception_ptr to std::bad_alloc. Not ideal however still my main purpose was to continue notifying and then rethrow all the exceptions again with as small risk (of another failure) as possible.
Yes that's a good one though the stack trace should be captured in one go before you throw. The trouble is this isn't possible in a platform-independent way; I'm hoping someone will come up with platform-specific implementation. I will add this support as soon as it's available, I do believe it is a very valuable diagnostic tool.
Yes. It would be better to get the stack trace before throwing. However for now (and I guess for long) it is not possible. While adding stack trace in catch blocks during unwinding is. As it comes to stack trace I have thought a lot about it but anything I imagined required adding special code to the functions which are to be stack-traced (so likely every). I guess this could come down to a single auxiliary function call wrapped in a macro however still it is not a good solution. And off-topic here. :)
In fact yesterday I went ahead and implemented it on my system, seems fine. I'll do some more testing and I'll commit it to trunk soon.
Nice surprise. Thanks. Adam Badura