Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-14 19:12:26

On Wed, Dec 14, 2016 at 3:44 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
wrote:

> 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