On Sun, Aug 15, 2010 at 5:59 PM, David Abrahams <dave@boostpro.com> wrote:
At Sun, 15 Aug 2010 16:08:47 -0700, Emil Dotchevski wrote:
If I keep careful control over my exception types---for example, if I only throw PODs---I can reasonably expect that "throw x;" throws x
You can reasonably expect that even for non-PODs. By the time you end up getting a std::bad_alloc, I don't think it matters much whether it is emitted from some operator new or from a throw (possibly indirectly, from an exception object which allocates memory in its consturctor)
My point is that whether that matters to the application is not for you---the library author---to decide.
Well, but I have made that decision, at least as far as Boost Exception's error_info is concerned. The postcondition of the op<< defined by the library is that the error_info has been stored in the exception object. Op<< may throw std::bad_alloc or any exception emitted by the error_info's copy constructor, and it only has basic exception safety guarantee. This way, at the catch site we can reason about what error_info objects the exception has: catch(my_error & e) { assert(boost::get_error_info<my_info>(e)!=0); //proceed to format a user-friendly message } which in a top-level context would likely be followed by catch(...) { //oh crap print(boost::current_exception_diagnostic_information()); }
-- your process is in a pretty bad state already.
I wouldn't say that. Out-of-memory is a condition from which recovery is perfectly manageable.
In theory it is, but on most platforms wouldn't you just crawl to a halt due to swapping and/or get killed by the OS or the user? Even if that doesn't happen, how can you reasonably test that your program works correctly in this situation? Certainly, I wouldn't bet my ears that my own programs deal with all possible std::bad_allocs gracefully. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode