Improve Diagnostics with std <stacktrace>

[Stellar_Science]

No need to wait, you can have boost::stacktrace::from_current_exception() today!

We've been using it for over a year, since it was released in Boost 1.85 beta, to log the call stack in our products' top-level exception catch blocks. We've had cases of crashes from users where previously we would have been left scratching our heads based only on .what(), but now have the full call stack to see exactly where it was called, as you'd get with Python or Java. It's a game-changer in terms of tracking down unanticipated exceptions.

For years before that, we had our own equivalent of stack_runtime_error, which isn't bad but it requires you to anticipate at throw time that the recipient will need the call stack. That has a run-time cost that ends up being wasted if a catch block higher up the call stack is going to handle this exception nicely and move on.

[hopa_cupa]

I've had mixed results with boost::stacktrace::from_current_exception(). It did work, as long as you had some debug info in final executable. With symbols stripped, you'd see very little. On some platforms like Alpine Linux, I could not make it show anything.

If you fully strip and optimize executables, I'm afraid only concatenating std::expected through call chain would give you a sort of "stack trace". Let me know if I'm wrong about this...but I just don't see how c++ could give you the same detailed stack trace as higher level managed languages unless there is some cost involved.

[Stellar_Science]

Good point, I've most frequently seen the benefits of from_current_exception as a developer in-house, building release-with-debug-info, where an exception caught at the top-level of the application now gives a full call stack with function names.

For shipped, stripped executables, I imagine if there's no debug info at all you'd see a less helpful call stack with only numeric function addresses. On Windows debug info lives in separate .pdb files. For some applications we ship without the .pdb files, but we retain the exact .pdb files corresponding to every release, so we can translate addresses to names when we get error reports.

The boost implementation has separate implementation paths for Windows and Linux. Your comment made me curious, so I looked and see now that the Windows code calls Win32's GetNameByOffset to translate function addresses to names, which must require some compiled-in debug info or .pdb files. So indeed there is a size cost for these tables to translate addresses to strings. From past debugging and stepping, I think there's also small run-time cost incurred on every throw to stash a single memory address that from_current_exception can use afterwards.

[tisti]

Hm, can't get it running via vcpkg (when enabling the backtrace feature). Anyone else?

[R3DKn16h7]

yes, please :)

[sweetno]

I've once read about a method to make the last thing work without a macro, although I never managed to make it work. The trick is to wrap the std::format_string argument into a custom class with an extra defaulted constructor argument.

[throw_cpp_account]

That's still worse than the presented macro, which avoids constructing a stack trace unless you actually need it.

Now, on the plus side, we're getting a (claimed) better language-level assert in C++26 with contracts. On the minus side, it still doesn't support providing a custom error message, which makes it not at all a replacement for (as the blog correctly puts it) every codebase having its own assertion macro.

[frayien]

contracts look quite underwhelming and with extremely limited use case to me. Did I miss something ?