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
On Mon, Feb 14, 2022 at 5:39 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote: 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
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).