Hacker News new | ask | show | jobs
by shepmaster 1038 days ago
> 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

2 comments

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.

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.