Re: Diagnostic improvements in 1.78/1.79

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2022-02-15 02:11:02

On Mon, Feb 14, 2022 at 5:39 PM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:
> On 15/02/2022 13:50, Peter Dimov wrote:
> > It's nice to have stack traces, but we can't realistically make
ThrowException
> > depend on Stacktrace, for several reasons. First and least, dependency
cycles.
> > Second, Stacktrace is not header-only, so all header-only libraries
that throw
> > exceptions will acquire a compiled dependency, which is a massive pain.
> >
> > And third, even for compiled libraries, the way Stacktrace uses
> > separate library per backend makes it hard to express the dependency
> > in b2 or CMake, because you have no idea what target your library
> > needs to link to.
> Perhaps StackTrace could be split into a capture-only component that has
> the properties you desire and a formatting component for the rest?
>
> Although I suspect platform differences for stack capture would likely
> make having it be header-only too impractical.  Still, I usually regard
> header-only as a misfeature anyway.
>
> What's probably a more practical solution might be to have potential
> throw sites declare a context object on their stack.  Any Boost-aware
> throw that occurs while these objects are on the stack would capture
> whatever additional information is requested by the context objects that
> are still in scope at the time.  This might be a stack trace, a source
> location, a plain string, or any other context info (e.g. method
> parameters) that seems useful.

On Mon, Feb 14, 2022 at 5:53 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:
> I think I like Emil's user-provided handler better, because with it the
user would
> control whether and what is collected.

There are two aspects of this: whether or not the information can be
collected (the ability to collect it means you're coupled to e.g.
Stacktrace, which you might not want), and whether or not the information
is in fact collected (e.g. we don't want to spend cycles generating a stack
trace if the error handlers don't care for it).

In terms of the latter, Gavin quite literally describes Boost LEAF. It is
indeed possible for "Boost-aware" throws to automatically detect what info
is actually needed for error handling, and only spend cycles capturing
that. This is exactly how leaf::on_error works.

However, the user-provided handler is better in that the coupling is only
in the user code. What Gavin proposes can still be done in that handler,
and then Boost can provide suitable implementations (perhaps including one
that is based on LEAF).