Hacker News Reader

Comment by frontfor | Hacker News Reader

Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.

View on HN

Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes.

Using "fmt.Errorf" is lean and painless compared to defining custom errors.

And be very careful in constructing your error messages so that grepping the error string does not return you 50 matches. It's not the same as getting the error message + file name + line number.

This is the whole story of Go, they pick something established and reimplement a heavily cut down version of it for "reasons", then slowly catch up to competition over the next decade or so.

It’s still not stack traces for every error, which is the default in every other language with stack unwinding.

In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.

Reply on news.ycombinator.com