$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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