Re: [boost] [exception] ostringstream like

Subject: Re: [boost] [exception] ostringstream like
From: David Abrahams (dave_at_[hidden])
Date: 2010-08-15 15:45:39

At Sun, 15 Aug 2010 12:25:50 -0700,
Emil Dotchevski wrote:
> 
> On Sun, Aug 15, 2010 at 11:56 AM, David Abrahams <dave_at_[hidden]> wrote:
> > At Sun, 15 Aug 2010 11:26:30 -0700,
> > Emil Dotchevski wrote:
> >>
> >> > and may fail to allocate the needed memory
> >> > for the string and stream, thus maskign the initial
> >> > exception with some bad_alloc.
> >>
> >> This concern is not valid because the C++ standard permits the
> >> runtime code
> >
> > Do you mean the runtime library?
> 
> No, I mean the generated code.

Code generated by what?  The throw-expression?  Sure.  The code that
is generated to throw the exception once it has been constructed?  I
don't think so.

> >> to run out of memory while trying to throw an
> >> exception, which presumably may result in a std::bad_alloc.
> >
> > If not, I don't think that invalidates the concern at all. Â It's
> > application- dependent whether or not the originally-intended
> > exception is more important information than the knowledge that memory
> > was running short at the point of the throw.
> >
> > If so, I wouldn't presume that it would throw bad_alloc in that case,
> > in real implementations. Â Usually this sort of thing falls under
> > "violating implementation limits" and invokes undefined behavior.
> 
> Stroustrup, The C++ Programming Language, Special Edition, page 371:

Please, don't quote that section to me.  I know where most of that
section came from, and it's a rather loose interpretation of the
source material (and the standard).

> "Throwing an exception requires an object to throw. A C++
> implementation is required to have enough spare memory to be able to
> throw bad_alloc in case of memory exhaustion. However, it is possible
> that throwing some other exception will cause memory exhaustion."
> 
> This stops short of saying that it might result in a std::bad_alloc
> but it seems permitted.

If you can find a place in the standard that says "throw x" is
permitted to throw a bad_alloc when x is not an instance of bad_alloc,
I'll buy it.  Otherwise, no.

> Since throwing (anything other than std::bad_alloc) can fail, you can
> think of the postcondition of throwing an exception to be that the
> exception was thrown successfully. Exceptions being the usual way to
> enforce postconditions, I think it is natural to permit a different
> exception to propagate instead.

It may be natural.  That still doesn't invalidate the OP's concern.
Mostly I'm reacting to your statement that the concern isn't valid,
which seems far too strong.  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 until I violate implementation limits
(and then I suppose then a bad_alloc is as good an expression of
undefined behavior as anything else).

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com