Hacker News Reader

Comment by malisper | Hacker News Reader

Can someone help me with what seems to be a basic problem? How are you supposed to get stack traces for errors in Go? You can wrap an error every time you return one, but this omits useful information like the line numbers. Not to mention, a significant amount of the code you are writing is going only to providing helpful error messages.

Alternatively, it looks like there are libraries out there[0] that will include stack traces for you. It seems weird to me that it's necessary to use an external library to get what seems like it should be built into the language.

Can anyone enlighten me?

Edit: Forgot to include the reference:

[0] https://github.com/pkg/errors

View on HN

github.com/pkg/errors is a popular solution to this problem

Indeed! In my opinion, Dave Cheney's error package is a better design than the Go 1.13 built-in mechanism, because it's more explicit. It's easy to forget a %w after being so used to %v, but errors.Wrap(err, ...) is pretty darn clear, as is errors.Unwrap.

As far as I'm aware, there are only two native ways to make an error unique enough to trace: Wrapping it with a unique string, or throwing a panic. You might be able to do something clever with panics by throwing them and then catching them to resume the thread, but I've never seen this done outside a few places in the Go standard library.

IIRC this is the suggested way to get a stacktrace. Panic and either recover or fail.

What? You're gonna need to link a source for that, because everything I've ever read is that panics are for catastrophic failure and should not be used for routine error handling.

Rob Pike has this to say:

Our proposal instead ties the handling to a function - a dying function - and thereby, deliberately, makes it harder to use. We want you think of panics as, well, panics! They are rare events that very few functions should ever need to think about. If you want to protect your code, one or two recover calls should do it for the whole program. If you're already worrying about discriminating different kinds of panics, you've lost sight of the ball.

Unless edited, I don't think that's what GP said. Panics are the way to get stacktraces, not the way to routinely handle errors.

Your top level comment about 403 errors made me assume you did not know about panic. Obviously your particular situation may have prevented it but I've always built Go programs from source (not linking binaries) which means I could always panic whenever I needed a stack trace.

Panics provide stacktraces, but are not the way to get stack traces. runtime/debug has the API to generate stacktraces.

github.com/pkg/errors is the ubiquitous library for seamlessly including stacktraces in errors

You can call runtime.debug.Stack() to create your error with a proper stack trace.

Reply on news.ycombinator.com