Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-06-22 08:23:03

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.

I looked at a recent boost/throw_exception.hpp.  It includes boost/exception/detail/attribute_noreturn.hpp.  That creates a dependency inversion that is unfortunate.  That is, a top-level header file depends upon a header file of a library's files.  That header is very short and has nothing Boost.Exception specific, so the code could be moved into boost/throw_exception.hpp or boost/detail/attribute_noreturn.hpp, for example.

The header also conditionally includes the non-trivial boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions:

boost::exception_detail::refcount_ptr
boost:: error_info
boost::exception
boost::exception_detail::error_info_base
boost::exception_detail::type_info_
boost::exception_detail::error_info_container
boost::exception_detail::get_info
boost::exception_detail::get_diagnostic_information()
boost::exception_detail::copy_boost_exception()
boost::exception_detail::set_info()
boost::exception_detail::error_info_injector
boost::enable_error_info()
boost::exception_detail::clone_base
boost::exception_detail::clone_impl
boost::enable_current_exception()

If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown.

This is a non-trivial set of changes to make to the top-level header.  I didn't follow the discussion at the time, but I'll presume there was a lot of discussion about the type and extent of these changes and that it was considered a good idea.  In hindsight, I agree with Robert's assertion that there should have been a replacement function, boost::exception::throw_exception() or similar, to introduce the new functionality.  Whether the existing function needed to be deprecated is a separate issue.  The result is that libraries could knowingly choose the new version, and a dependency on Boost.Exception, or, if warranted, stick with the old.

As things now stand, if there is good reason to avoid the new version, it can only be done by defining BOOST_EXCEPTION_DISABLE, which affects an entire build.

> The extent/nature of any problem it created or didn't create is
> not relevant here.   Just the injection of a new body of code
> which replaced two lines and added no functionality used/needed
> by the serialization library makes the any library which used
> boost::throw_exception "bigger" for no reason.

The issue you're raising, as I understand it, is dependency inversion: the top-level header brings a dependency on Boost.Exception.

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

> 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().  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.  (I don't pretend to know what your concerns are.  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.)

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