On Wed, Dec 14, 2016 at 3:44 PM, Andrey Semashev
On 12/15/16 02:27, Peter Dimov wrote:
Nat Goodspeed wrote:
... perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the
stacktrace at the throw point.
This sounds like a pretty good idea, although I'm not sure if we can enable it by default as people have historically been very sensitive to changes to BOOST_THROW_EXCEPTION. But an opt-in macro should be fine and very useful as one would automatically get stack traces from every use of BOOST_THROW_EXCEPTION. Hello Java.
I've not taken a look at the proposed Stacktrace library, but from what I know obtaining a stacktrace is typically a rather expensive operation. I expect it to be no less expensive than throwing the exception. That's probably too much to pay for by default. Plus, it adds one more dependency on another library via such a core component as BOOST_THROW_EXCEPTION.
I think, a new macro in a separate library (i.e. not in throw_exception) would be more preferable.
I think that the stack trace should be embedded by default by boost::throw_exception (not by BOOST_THROW_EXCEPTION), with a new configuration macro that can be used to disable this new behavior. I think that performance concerns are unwarranted in this case, since throwing exceptions is expensive already; it is generally not a good idea to assume anything about its performance. And stack trace is very useful bit of information to have. That said, I am much more concerned about added dependencies, because boost/exception/exception.hpp (which boost/throw_exception.hpp includes) is carefully designed to have NO dependencies. I would be open to providing special hooks into the boost::exception class to support stack trace (similarly to how there is special storage for __FILE__ and __LINE__), as long as the dependencies make sense. Emil Emil