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
> 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)
//proceed to format a user-friendly message
which in a top-level context would likely be followed by
>> -- 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
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk