On 15/02/2022 14:53, Peter Dimov wrote:
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.
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.