Hacker News Reader

Super interested in your approach to error wrapping! It’s a feature I haven’t used much.

I tend to use logs with line numbers to point to where errors occur (but that only gets me so far if I’m returning the error from a child function in the call stack.)

View on HN

Simply wrap with what you were trying to do when the error occurred (and only that, no speculating what the error could be or indicate). If you do this down the call stack, you end up with a progressive chain of detail with strings you can grep for. For example, something like "processing users index: listing users: consulting redis cache: no route to host" is great. Just use `fmt.Errorf("some wrapping: %w", err)` the whole way up. It has all the detail you want with none of the detail you don't need.

So hand rolled call stack traces? I just don’t understand why this is better than exceptions.

Reply on news.ycombinator.com