Get Backtrace Access

[mitsuhiko]

Can we can an optional feature which gives access to the underlying backtrace object? I am trying to get backtraces reported into sentry but I can't access the frames currently.

The only workaround I have right now involves parsing the string which is not very nice.

[withoutboats]

Totally in favor of adding these APIs, just worried about finding the exact best API shape that we can stabilize forever. I don't know much about these kinds of backtrace integrations you're trying to do, nor about the low level details of implementing backtraces, so I'm not confident that I can make good decisions regarding the API we can guarantee.

[mitsuhiko]

I was hoping in a way that the backtrace crate would just stabilize but sadly it hasn't really turned out that way so far :(

[withoutboats]

I'd really like to see backtrace added to libstd (with a ZST dummy in libcore, like failure has). That way, users could also control all library backtraces in a convenient and guaranteed way, rather than relying on cargo features like failure does. And ideally, that type would then have peoples' attention to give it a really solid API.

[withoutboats]

@mitsuhiko I was talking to Aaron earlier this week and moving backtrace into std is probably the most logical next step for library access to backtraces in Rust.

I wonder if you'd be interested in writing an RFC about this, and the API that a shared/standardized backtrace should have?

[mitsuhiko]

@withoutboats in a heartbeat.

[mitsuhiko]

Just wanted to say that I did not forget about this, I just did not have time yet to get to it. We're currently parsing the string representation as a workaround ;)

[yaahc]

Hey, right now the crate https://github.com/athre0z/color-backtrace is trying to add support for nicely printing failure::Backtraces, but it needs access to the underlying backtrace object to do so, as mentioned by the author @athre0z in athre0z/color-backtrace#1

Is there anything I can do to help? I'm happy to submit a PR or whatever else is necessary, but I'll definitely need some guidance, especially given that based on what I read here, the correct solution isn't necessarily obvious.

[mitsuhiko]

The stdlib now depends on backtrace and it’s less work now to expose a backtrace object from the stdlib. I started an attempt this week during our hackweek but I got distracted by other things.

I would not want to expose the current backtrace object from failure but fix uo std error to carry a backtrace first instead.