abhinavg

pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.

errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.

This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.

The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.

As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.

Comment · 2 years ago

Thanks! No, just one of the maintainers with a free evening.

Show HN: Error return traces for Go, inspired by Zig github.com

133 abhinavg 2 years ago 84 comments

Comment · 3 years ago

I'm a happy duck.com address user. I can answer these questions:

What it is: It gives you private throwaway email addresses. Instead of signing up for a website with <real>@gmail.com, use <fixed>@duck.com. It will forward the email to <real>@gmail.com after removing any trackers from it. It also lets you generate <random>@duck.com addresses on demand. If you sign up for something with <random>@duck.com, and they start spamming you, you can turn the email address off without doing anything to <real>@gmail.com or <fixed>@duck.com.