On 2/15/22 03:50, Peter Dimov via Boost wrote:
Gavin Lambert wrote:
Not sure about gcc/clang/Linux, but with msvc/Windows it's possible to recover a stack trace from any thrown exception regardless of type, without any fanfare at the throw site (albeit only by relying on some fugly compiler internals).
Not sure that's true for Linux/macOS. Windows exception handling is unique in that the stack is not touched (except for running the destructors) during unwinding so the frames are still intact.
But the destructors can clobber the stack, can't they?
Although also I thought one of the main selling points of Boost.StackTrace is that it's nearly free to capture a trace at time of exception; it's only formatting into human-readable that's potentially expensive, but that only happens at the other end on demand.
Personally, I find passing around source-locations to be completely useless (and subject to binary bloat and undesirable disclosure, as Niall pointed out). Stack traces all the way.
Now that Stacktrace is in the C++23 standard, there's an interesting proposal to make stacktrace captures automatic on throw:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2370r2.html
although I'm not sure it will fly, even for C++26.
Note the "Recommend to turn off by default" in Design decisions. Capturing the stacktrace isn't cheap, even without symbol resolution, so doing this everywhere by default is unacceptable, IMHO. BTW, the original discussion was here: https://lists.isocpp.org/std-proposals/2021/04/2539.php
But there's more to it. If you follow a straightforward style in which you immediately throw on error, capturing stack traces on throw works well. But if your library is written to use error codes internally, so that it can expose a dual API to the user, that is, to be usable with either exceptions or error codes, things are not so rosy. That's because failures are propagated upwards through several layers using error codes, and only at the last layer is that turned into an exception. So you get a stack trace from that point upwards, which is not as helpful.
This is one of the reasons why I keep the dual error reporting down to the lowest level in Boost.Filesystem. But I admit, writing such code is a pain, to say the least.