garrinm (u/garrinm) - Readit News

garrinm commented on Show HN: Stack Error – ergonomic error handling for Rust github.com/gmcgoldr/stack... · Posted by u/garrinm

lilyball · 3 months ago

If the macros only exist to get file and line information, you could do the same thing by using `#[track_caller]` functions combined with `std::panic::Location` to get that same info. For example, `stack_err!` could be replaced with

  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()))
      }
  }

such that you call `.map_err(StackError::new_location("data is not a list of strings"))`. A macro is nice if you need to process format strings with arguments (though someone can call `StackError::new_location(format_args!(…))` if they want), but all of your examples show static strings so it's nice to avoid the error in that case.

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()`.

garrinm · 3 months ago

Thanks for the insight, I wasn't aware of `track_caller`. I'll definitely be looking into this. I was scratching my head trying to figure out how to make file and line number usage consistent and customizable, this looks like the answer!

You're also right that this will pretty much eliminate the need for macros.

That's also a very key insight about Display vs. Debug printing. I'll be looking into that as well.

Thank you for the thoughtful reply.

garrinm commented on Show HN: Stack Error – ergonomic error handling for Rust github.com/gmcgoldr/stack... · Posted by u/garrinm

rhabarba · 3 months ago

I still prefer the Anyhow solution, but I like the approach here.

garrinm · 3 months ago

Anyhow still makes things easier for application development. The main drawback is that the resulting error type doesn't implement std::error::Error, so it's not suitable for library development (as pointed out in the anyhow documentation). Stack Error is a bit less ergonomic, but suitable for library development.

garrinm commented on Show HN: Stack Error – ergonomic error handling for Rust github.com/gmcgoldr/stack... · Posted by u/garrinm

shepmaster · 3 months ago

I hope to read through your crate and examples later, but if you have a chance, I’d be curious to hear your take on how Stack Error differs from my library, SNAFU [1]!

[1]: https://docs.rs/snafu/latest/snafu/index.html

garrinm · 3 months ago

I played around a bit with SNAFU a couple of years ago, but I'm haven't worked deeply with the library so there might well be some features I'm not aware of.

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.

garrinm commented on Stack Error – Pragmatic error handling for Rust github.com/gmcgoldr/stack... · Posted by u/garrinm

garrinm · 9 months ago

Stack Error is a pragmatic error handling library for Rust that provides helpful messages for debugging, and structured data for runtime error handling.

Features:

- Informative error messages: stack error messages and optionally add file/line context to your messages. This helps convey not just what went wrong, but also how it went wrong, making debugging faster.

- Programmatic error handling: include optional error codes and URIs for robust runtime handling.

- Library-Friendly: define custom error types easily while staying compatible with Rust’s error ecosystem.

If designing good error structures for your projects slows you down, and you need something more library-friendly and structured than anyhow, Stack Error might be what you’re looking for.