[HN Gopher] Show HN: Stack Error - ergonomic error handling for ...
       ___________________________________________________________________
        
       Show HN: Stack Error - ergonomic error handling for Rust
        
       Stack Error reduces the up-front cost of designing an error
       handling solution for your project, so that you focus on writing
       great libraries and applications.  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.
        
       Author : garrinm
       Score  : 20 points
       Date   : 2025-05-18 18:46 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tevon wrote:
       | This is awesome! Will give it a try in my next project.
       | 
       | 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 wrote:
         | Rust provides file!, line! and column! macros that expands into
         | a compile-time constants that the compiler embeds then into the
         | executable. This way no source map at runtime is necessary as
         | the relevant errors are constructed from those constants.
         | 
         | Presumably StackError just uses those macros.
         | 
         | But for debugging a source map is still necessary and is a part
         | of various debug formats.
        
       | rhabarba wrote:
       | I still prefer the Anyhow solution, but I like the approach here.
        
         | IshKebab wrote:
         | Isn't this strictly superior to Anyhow? What do you like more
         | about Anyhow?
        
       | shepmaster wrote:
       | 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
        
       | lilyball wrote:
       | 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()`.
        
       ___________________________________________________________________
       (page generated 2025-05-18 23:00 UTC)