On Mon, Feb 14, 2022 at 6:20 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 15/02/2022 14:53, Peter Dimov wrote:
What's probably a more practical solution might be to have potential
sites declare a context object on their stack. Any Boost-aware throw
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.
I think I like Emil's user-provided handler better, because with it the user would control whether and what is collected.
I did consider mentioning that, but what I don't like about that option is that it leaves things a bit too vague.
(And in terms of ThrowException itself, it's fundamentally equivalent to the NO_EXCEPTIONS path, by making it call a user-provided method to do the actual work. Which then seems to defeat the point of having it be a library at all.)
It puts the burden entirely on the end-user to select the mechanism for error info propagation, and library authors would have a harder time interfacing with it.
That is true, but it requires coupling, and to me this is not appropriate. Whatever approach we pick, it should be easy for the user to stitch up whatever is needed, but all dependencies should be opt-in.