4 ms·

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

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.

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.