5 ms·

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 retur

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 https://github.com/pkg/errors

alecthomas 7y ago
github.com/pkg/errors is a popular solution to this problem
- oppositelock 7y ago
  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.
jniedrauer 7y ago
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.
- sjtindell 7y ago
  IIRC this is the suggested way to get a stacktrace. Panic and either recover or fail.
  - jniedrauer 7y ago
    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.
    - BlueDingo 7y ago
      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.
      - omegabravo 7y ago
        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
- _ph_ 7y ago
  You can call runtime.debug.Stack() to create your error with a proper stack trace.

alecthomas 7y ago

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

oppositelock 7y ago
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.

jniedrauer 7y ago

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.

sjtindell 7y ago
IIRC this is the suggested way to get a stacktrace. Panic and either recover or fail.
- jniedrauer 7y ago
  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.
  - BlueDingo 7y ago
    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.
    - omegabravo 7y ago
      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
_ph_ 7y ago
You can call runtime.debug.Stack() to create your error with a proper stack trace.