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