Re: [boost] [exception] ostringstream like

Subject: Re: [boost] [exception] ostringstream like
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-08-15 23:15:23

On Sun, Aug 15, 2010 at 5:59 PM, David Abrahams <dave_at_[hidden]> 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