$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-22 13:30:13
Stewart, Robert wrote:
> Robert Ramey wrote:
>> Dave Abrahams wrote:
>>>> I mean, if there is a problem with boost::throw_exception or
>>>> any other part of Boost Exception, I'd like to know about
>>>> it.
>>>
>>> It seems clear to me from his posts that Robert wants to
>>> talk about the process and has forgotten any specifics about
>>> actual problems.
>>>
>> The problem was the gratuitious inclusion of a new dependency.
>
> Emil has described repeatedly why the change was not gratuitous.
> That you fail to recognize the value in the change does not make it
> gratuitous.
If you like you can substitute the term "unnecessary"
> I looked at a recent boost/throw_exception.hpp. ....
...
> The issue you're raising, as I understand it, is dependency
> inversion: the top-level header brings a dependency on
> Boost.Exception.
That's it.
>> It makes the library more "fragil". It means I have I a new
>> place to look if something needs looking into. etc.etc.
>
> As Nevin pointed out, your code will always be subject to the changes
> in those libraries on which it depends.
LOL - that's precisely why I don't want to see unnecessary
dependencies introduced. Especially when I'm not looking.
> The more dependencies you
> introduce, the more fragile your code becomes, but there's a great
> deal of benefit to reuse, too. The only issue in this case is that
> one can reasonably expect a top-level header to avoid dependencies on
> libraries.
Personally I wouldn't say it's the only issue. But I'm glad we can
agree that it's its a BIG issue.
>> So we'll just move on as Vicente suggested. That will be
>> satisfactory from my standpoint.
> That is the only way forward, if there is good reason to avoid the
> now longstanding changes to boost::throw_exception().
And how is that to be determined? Who would do that work?
> However, you should work with Emil to be sure you correctly and
> fully understand the issues before deciding that you cannot accept
> boost::throw_exception() as is.
Ahhh - this is the rub.
> (I don't pretend to know what your concerns are.)
LOL - you described them very well in your previous post.
And you've supported your argument for my (general/abstract?)
concerns with a meticulous analysis of the current implementation of
boost::throw as particular example. Thank you for that.
> I just don't want to see a new throw_exception()
> variant if there isn't a compelling reason, and I don't consider your
> fragility argument compelling in this case.)
You've looked into this - did you see any "compelling reason" to
inject this code into the serialization or any other library?
Robert Ramey