Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-06-22 13:10:32

Robert Ramey wrote:
> Stewart, Robert wrote:
> > Robert Ramey wrote:
> >> Dave Abrahams wrote:
>
> > I looked at a recent boost/throw_exception.hpp.
> [snip]
> > 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.

OK, good.  I'm glad we've succinctly and clearly identified your concern.  That means there's an opportunity to make progress and set policy.

> >> It makes the library more "fragil".   It means I have I a
> >> new place to look if something needs looking into. 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.

I get that.  If the change was unnecessary, then it adds a dependency that complicates your maintenance.  However, there's still the question of whether the dependency was necessary.  You're convinced it wasn't, I know.

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

Clearly, those (you) with a concern would make a proposal, elicit discussion of the idea and proposed solution, then, if deemed acceptable, determine what sort of review process is warranted.

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

Yes, and it's a very important first step.

> > (I don't pretend to know what your concerns are.)
>
> LOL - you described them very well in your previous post.

I'm not so sure.  You've gone to some lengths to avoid the Boost.Exception dependency and, I presume, it was not motivated simply because you did not want Serialization being dependent upon Exception.

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

I don't know what benefits it may bring to Serialization and that's the crux of the matter.  Roger Martin and Fabio Fracassi have both described the value they get from Boost.Exception and, presumably, from boost::throw_exception(), that they don't get from Serialization precisely because you have avoided the dependency.  It is for reasons like those that I suggest reevaluating whether Serialization should accept boost::throw_exception() as is and avoid the fork.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.