You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for tracing with Std::panic::Location (Feature Request) #142
It's sometime useful to simply trace the location of an error's origin, through nested callers and micro managed errors.
Compared to already existing Backtrace, it might be more concise, and thanks to std::panic::Location and #[track_caller] being stabilized it wouldn't need nightly.
Thanks for the great crate
Reacted by Zyansheep, Nubis, Kraktus, uttarayan21, Maël Lefeuvre, Sebastian Wilzbach, Andrew Straw, stormshield-guillaumed, Scott Robinson, Aaron Kutch and 7 more
There is an example of how an error report can looks with locations:
Failed to handle protocol
0: Failed to handle incoming content, query: blabla, at src/protocol/handler.rs:89:22
1: Failed to reading next message at queue 5 of 10, at src/protocol/loop.rs:254:14
2: Failed to decode `01010001001010001` to ProtocolHeader, at src/protocol/codec.rs:90:14
3: serde_json(invalid character at position 1)
Activity
Allen-Webb commentedon Oct 6, 2021
I also think some kind of backtrace chaining through source errors is really needed for thiserror.
0xForerunner commentedon Feb 11, 2023
Anyone know if there are plans to implement this? It looks like it should be pretty easy. A basic implementation looks like this
To me this feature is basically begging to be included in thiserror.
feat: Add std::panic::Location support for error derive macro
vlad20012 commentedon Nov 10, 2025
A good explanation of why Location in errors is very useful: https://greptime.com/blogs/2024-05-07-error-rust#present-error-to-end-users
There is an example of how an error report can looks with locations: