Subject: Re: [boost] throw or boost::throw_exception?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-31 07:57:03
On Saturday 31 May 2014 12:13:55 John Maddock wrote:
> >> I'm starting to wonder if all the "workaround" headers should be moved
> >> into Config (provided they don't depend on anything else). This would
> >> be one candidate I guess?
> > You mean boost/exception/exception.hpp? That doesn't look like a
> > workaround
> > header.
> The rationale is that boost/throw_exception.hpp started off at least as
> a workaround for compilers with exception handling turned off (and is
> still required for such), the fact that it pulls in one header from
> Boost.Exception as well is a side effect, but a not-unhappy one in that
> it stops endless "why do I need to depend on Boost.Exception"
> discussions, if that one header shift to Config.
I'm still missing which particular header you refer to, sorry. It seems
boost::exception is a crucial part of Boost.Exception, I don't think that
moving boost/exception/exception.hpp would be a good idea. Boost.Exception
should be maintainable, having its fundamental part somewhere else precludes
Move boost/throw_exception.hpp and add a dependency on Boost.Exception to
Boost.Config? No, I don't think that is a good idea either.
Move boost/throw_exception.hpp and remove support for Boost.Exception (and
hence the dependency)? Possible, but that also reduces user experience with
Boost. I very much like the additional information Boost.Exception provides
Add a new macro, say BOOST_THROW, to Boost.Config that will only deal with the
configurability aspect of BOOST_THROW_EXCEPTION? Then make
BOOST_THROW_EXCEPTION use BOOST_THROW internally. Leave all current headers in
their places. This sounds like the most sensible plan to me. Although I'm a
little worried that people will start ignoring BOOST_THROW_EXCEPTION and hence
we'll lose the additional information in exceptions we have now.
Personally, I see no problem with dependency on Boost.Exception, so I would
have left everything as is. But if I have to choose, I'd prefer the last
solution of the above.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk