Stack Error has three goals:
1. Provide ergonomics similar to anyhow.
2. Create informative error messages that facilitate debugging.
3. Provide typed data that facilitates runtime error handling.
Stack Error has three goals:
1. Provide ergonomics similar to anyhow.
2. Create informative error messages that facilitate debugging.
3. Provide typed data that facilitates runtime error handling.
I think SNAFU is more like a combination of anyhow and thiserror into a single crate, rather than Stack Error which leans more heavily into the "turnkey" error struct. Using the Whatever struct, you get some overlap with Stack Error features:
- Error message are co-located.
- Error type implement std::error::Error (suitable for library development).
- External errors can be wrapped and context can easily be added.
Where Stack Error differs:
- Error codes (and URIs) offer ability for runtime error handling without having to compare strings.
- Provides pseudo-stack by stacking messages.
Underlying this is an opinion I baked into Stack Error: error messages are for debugging, not for runtime error handling. Otherwise all your error strings effectively become part of your public interface since a downstream library can rely on them for error handling.
impl StackError {
#[track_caller]
fn new_location(msg: impl Display) -> Self {
let loc = std::panic::Location::caller();
Self::new(format!("{}:{} {msg}", loc.file(), loc.line()))
}
}
The use of `std::panic::Location` also means instead of baking that into a format string you could also just have that be an extra field on the error, which would let you expose accessors for it, and you can then print them in your Debug/Display impls.
Speaking of, the Display impl really should not include its source. Standard handling for errors expects that an error prints just itself with Display because it's very common to recurse through sources and print those, so if Display prints the source too then you're duplicating output. Go ahead and print it on Debug though, that's nice for errors returned from `main()`.
The macros are used for two purposes: one is (as you pointed out) to include this information in the string. The other is to reduce the amount of boilerplate closures in operations like `.map_err(|x| StackError::new(x))`. I think using `track_caller` I can make a cleaner separation here and use macros just to reduce the boilerplate.
That's also a very key insight about Display vs. Debug printing. I'll be looking into that as well.
Thank you for the insights.
tevon•5h ago
How does it keep track of filename and line number in a compiled binary? I'm fairly new to rust libraries and this doesn't quite make sense to me. I know in JS you need a source-map for minification, how does this work for a compiled language?
fpoling•5h ago
Presumably StackError just uses those macros.
But for debugging a source map is still necessary and is a part of various debug formats.