Re: [boost] [exception] ostringstream like

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

On Sun, Aug 15, 2010 at 12:45 PM, David Abrahams <dave_at_[hidden]> wrote:
> At Sun, 15 Aug 2010 12:25:50 -0700,
> Emil Dotchevski wrote:
>> 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).

Evidently you're more familiar than me with this matter. The paragraph
in the standard that defines how the memory for the exception is
allocated has a reference to the section which defines the semantics
of the general allocation functions, but this may be a rather loose
interpretation of the standard, I'm not an expert.

>> 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.

Yes it was far too strong, my bad.

> 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) -- your process is in a pretty bad state already.

The reason why I'm reacting to this type of concerns is that typically
they're motivated by a desire to control exactly what exceptions a
particular function is permitted to emit. It is this type of concerns
that have lead to the infamous exception specifications in the
standard. In other cases, these concerns lead to exception type
translation code which usually can be summarized as "catch(x) { throw
y(x); }. Often, this doesn't make it easier to deal with x, but now
the code that deals with x is coupled with y too.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode