Hacker News Reader

Comment by JoelJacobson | Hacker News Reader

Author of `wherr` here. I can totally relate to the situation you describe. That's exactly what happened to me, and why I created wherr. At first, I couldn't understand why I couldn't find the `?` line in the backtrace.

`anyhow`'s `with_context` is great, but seems to require you to modify each line of code where errors are created, to find the error.

With `wherr`, you only need to add one line of code, `#[wherr]`, per function.

View on HN

That doesn’t seem like a meaningful DX improvement and seems more stylistic, no?

Really we’d need rustc to support some kind of AOP technique that lets you inject code at every call site somehow. That way you write the extra context info in a single macro that gets applied transparently for you.

That being said, SNAFU’s approach seems better in the interim. Just add a Location (and presumably there’s a backtrace option too) to your error type and it’s captured automatically without any macros.

Correction: seems like the Error crate is working to natively acquire support for reporting backtrace automatically [1]. Extending that to add line number support seems reasonable. That way you get an upgrade across all codebases without anyone needing to make any changes.

https://github.com/rust-lang/rust/issues/53487

I like the idea of not even having to write a line of code per function.

Maybe `cargo fmt` could be extended to add such annotations automatically? That way, it wouldn't be "magic", since the macros would be spelled out in the code, but the manual work of adding them would be eliminated.

> and presumably there’s a backtrace option too

There is [0].

However, I'm not personally a fan of backtraces (or the lightweight location information, really). I'd much rather provide what I call a "semantic backtrace", which is where almost every Result-returning function is annotated by the programmer with a unique `.context(...)` call. This often results in a better error to the user ("couldn't connect to the server <because> couldn't get the URL <because> couldn't open the config file <because> couldn't open file ..."). The programmer can identify the location of the error due to the uniqueness of each context.

Backtraces are an easier way of getting similar information, but much less useful to the end user. I'd rather people prioritize the end user over the developer, so that's what I try to encourage in SNAFU.

That being said, plenty of people want location / backtrace information, so SNAFU tries to support those as well.

[0]: https://docs.rs/snafu/latest/snafu/struct.Backtrace.html

Yes, this is how I prefer to do it as well. Takes some work to consistently remember to put in context information, but you can add in things like the filename for those NotFound errors, and so on.

Semantic backtraces should be visible to the system administrator. In a DevOps shop, that's your developer, not your end user. This mentality works for application software the end user is running on their own hardware. Showing backtraces to users external to your system administrator is generally not desirable - you don't want to leak implementation details because they may reveal proprietary intellectual property or they may reveal internal details that can be used to compromise your security. User-facing errors where you're running software in a managed environment are typically carefully managed as explicit carveouts in terms of what information they will reveal.

Also, most users are non-technical. So semantic backtraces that are visible only end up helping a small, more technical subset of your customer base (even if your customer base is developers in my experience). You do want to be able to have a way to link a semantic backtrace to a specific error instance that a customer observed though.

Reply on news.ycombinator.com