Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-15 18:11:14

On Thu, Dec 15, 2016 at 11:21 PM, Emil Dotchevski
<emildotchevski_at_[hidden]> wrote:
> On Thu, Dec 15, 2016 at 11:26 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>
> The boost::exception type (which, again, does not depend on anything,
> boost/exception/exception.hpp does not include any headers) currently holds
> an int and a char const * for BOOST_THROW_EXCEPTION to store __LINE__ and
> __FILE__. The cost of adding the ability of boost::exception to carry a
> stack trace would be one more pointer (note: for this purpose it's possible
> to use Boost Exception's ability to transport arbitrary data in any
> exception, but that would make boost::throw_exception dependent on Boost
> Exception, which I've worked very hard to avoid so far.) That pointer can
> remain unused if the user chooses to turn off the automatic capture of the
> stack trace.

The problem is not the pointer per se. The problem is that your
proposal implies a dependency on the code that fills that pointer, the
Stacktrace library. Robert expands on the dependency injection and I'm
worried by performance degradation caused by this change.

I must say I'm not really buying the "automatic stacktrace from
exception" advantage. Really, the source file and line, combined with
sufficient logging, were quite enough for me for years; if there were
cases I wished to have a backtrace, they were rare enough I don't
remember one of them.

So please, just define a separate macro with this new feature and
leave BOOST_THROW_EXCEPTION as is.

The config macro to disable the stacktrace doesn't satisfy me. First,
because it is a way to opt out whereas I believe such a feature should
be an opt in as it is expensive. Second, because it doesn't work with
compiled binaries (e.g. distributed in package distros and Boost
installers). Third, I suspect this feature could be useful in a subset
of source code, e.g. a particular set of function calls or a scope,
while not so useful in other places of the application. For instance,
one might want to temporarily enable it to debug a particular place of
code without affecting the rest of the program. For that the feature
should be configurable in runtime.

What I'm thinking is that there could be a hook that would allow a
user-defined function to be called on the exception that is about to
be thrown. By default no hook is installed, so throwing an exception
works exactly as BOOST_THROW_EXCEPTION currently works.
Boost.Stacktrace could provide its hook, which the user could install
to enable automatic stacktraces. The important part is that this is
user's choice and that it decouples throwing the exception from
Boost.Stacktrace.