|
Boost : |
Subject: Re: [boost] [numeric] Applying trivial bugfix
From: Iain Denniston (iain.denniston_at_[hidden])
Date: 2012-02-28 13:33:07
> That's the way it was originally. Then the implementation of
> BOOST_THROW_EXCEPTION got changed creating unexpected behavior and side
> effects in all the libraries which used. So...
The thought of a new BOOST_HANDLE_EXCEPTION macro named "for historical
reasons" pains me. :(
Would it not then be a better idea to roll back to the old functionality
and have an additional macro (BOOST_THROW_EXTENDED_EXCEPTION?) to
provide the extended functionality the current macro provides? This is
probably how such a library would have been created if done now and
restoring what library authors intended seems like a good idea, plus if
new users of the current macro are not happy with it, then I suspect
some of those who have had it changed under their feet will be similarly
unhappy (though perhaps unaware).
I realise that given the macro is used widely through boost, changing it
is not something to be done lightly, but since this would effectively be
restoring previous functionality I don't see it as such an issue.
Additional configuration options to make BOOST_THROW_EXCEPTION ==
BOOST_THROW_EXTENDED_EXCEPTION and vice versa would allow users to make
a decision if the extra information is important to them and allow
others to avoid the costs when required (also this would provide
complete backwards compatibility with the current setup). Library
authors could make an initial call (based on the type of library), users
make the final decision.
Whatever the final decision, I'd at least like to see the option to make
all exceptions of one type or the other.
Iain
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk