failure
failure copied to clipboard
rust-lang-deprecated
Automatically Trim Backtraces
It would be nice if there was a way to automatically trim backtraces. I generally have about 12 useless frames above what I actually care about (where the error originates). It would be nice if failure could provide helpers to trim them down by chopping off stuff above known points (for instance when created via result_ext).
@withoutboats one is that it would be nice to access the frames like you can do in the backtrace api but that might be independent. If I had access to the frames I could trim it myself. But ideally there is just a trim() function which automatically chops off frames above some well known points (eg: result_ext, all internal functions that generate backtraces etc.)
That function would then set an internal offset that chops off the frame iterator above a certain frame.
There are several things we don't currently expose you would need to do this yourself:
- Mutable access to the backtrace, which
Errorcurrently doesn't provide. - Methods for manipulating the backtrace frame, I didn't expose these in my backtrace wrapper.
I think I'm more inclined to add that than to add any higher level abstraction; I think trimming backtrace frames is pretty niche & would want to limit that API surface to the Backtrace type.
The APIs also might need to be different from the APIs exposed by libbacktrace, because in no_std, Backtrace is a ZST. however I think libbacktrace currently returns slices for everything, so they could probably just be empty slices in that case.
WRT to the types: I wonder if it wouldn't be reasonable to have a no_std crate that provides a backtrace trait and frame types that can then be used from different things including this library. Because backtraces are really quite important and the fact that we have already so many of these types is not super great. In particular working with stacktraces is super useful, particularly also in tokio/distributed environments.
Back to topic though: would you be accepting patches to give the backtrace system a bit more functionality under the assumption that the ZST functionality is retained?
I think trimming backtrace frames is pretty niche
I think it's only niche because we have accepted pretty terrible stacktraces in Rust sadly. None of the backtrace libraries or rust itself format them out in a great way and they contain a lot of information that is counterproductive for debugging. In the past it was not much of an issue for me as I just generally write my own backtrace formatter but since fail hides all of the backtrace that's quite tricky now.
I would personally prefer to see libbacktrace upstreamed to std with no-op ZST equivalents in core; I'm unhappy with the current state of things.
Would love to see this but not going to push this until I think the design is great. Just because I'm afraid of a second std::error. What about having a #[doc(hidden)] api that is only used for a companion crate that could later change?
I was just about to make an issue for this as well.
Instead of trimming the backtrace itself, what about just adjusting the way it's printed? A good idea might be to emulate rustc, so when you set RUST_BACKTRACE = "1" it'll print a trimmed backtrace (removing the entry-point shim and the frames where we're starting to create a backtrace), but if you set RUST_BACKTRACE = "full" it'll give you the entire backtrace.
Considering the failure::Backtrace struct is an opaque type which is only useful for printing to the screen when the RUST_BACKTRACE variable is set, it's probably not necessary to make changes to the underlying backtrace from libbacktrace (i.e. add a trim() method).
