6 ms·

What about error stack traces? I find it crazy that you're supposed to grep error strings and pray they're all different.

pipe01 3y ago
You can do it yourself if you want using `runtime.Stack` and a custom error type
- minzi 3y ago
  Embarrassingly, I’ve been writing Go for a while but never really thought about it. Now that it’s been mentioned I’m curious why this isn’t baked in by default for errors. Does anyone know?
  - sapiogram 3y ago
    > I’ve been writing Go for a while but never really thought about it. Don't feel bad, I've tried to do this in some places, but I'm not sure it's worth it. It adds a ton of boilerplate to Go's already verbose error handling, since you need to wrap every error that gets returned from libraries.
  - icholy 3y ago
    Creating stack traces is expensive.
    - tbarbugli 3y ago
      you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU
      - Cthulhu_ 3y ago
        That's still under the assumption that errors are exceptional, rare, and require a stacktrace to debug. But most errors are not exceptional and do not need debugging, like idk, a row not found error in a database. A crash, sure, that might need a stacktrace to debug. But that's already in place.
      - kbolino 3y ago
        Good error-wrapping discipline works better than stack traces, because not only do you have a trace of the calling context, you also have the values that caused the problem. Granted, a stack trace "always works", but it will never have the values of important variables.
        Cthulhu_ 3y ago
        Now you mention it, a stack trace with function calls and all their arguments would be really powerful. But also expensive, ideally it would have zero overhead or only have the cost if you actually look at it / want to debug it.
        kbolino 3y ago
        One of the major optimizations is to pass function arguments in registers instead of on the stack. These registers might preserve their original values by the time you unwind the stack, but in many cases, probably won't. Preserving those values would lead to fewer available registers and/or more frequent register saving, which would create at least some overhead, even if you don't ever inspect it. There are probably lots of situations where it's worth it, though.
        derekperkins 3y ago
        We do both and it works great
  - closeparen 3y ago
    You’re supposed to prepend the context to an error before you return it, so the final error reads like a top-level stack trace: “handling request: fooing the bar: barring the baz: connecting to DB: timeout.”
  - kbolino 3y ago
    Well, how would that work? Errors are just values. They don't have any special meaning nor is there any special ceremony to create them. A panic must start from calling panic(); there's no function or special statement to create or return an error. It might be possible to augment every `error`-typed return such that the concrete type is replaced by some synthetic type with a stack trace included. However, this would only work because `error` is an interface, so any function returning a concrete-typed error wouldn't be eligible for this; it would also add a lot of runtime overhead (including, at the very least, a check for nil on every return); and it would cause issues with code that still does == comparisons on errors. On the whole, I think error-wrapping solves the problem of tracing an error well enough as the language exists today. If errors are going to start having some magic added to them, I think the entirety of error-handling deserves a rethink (which may be due, to be fair).
Xeoncross 3y ago
Errors are different in every stdlib or 3rd party package I've ever used. The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong. I love stack traces in Java, but I don't miss them at all in Go.
- the_gipsy 3y ago
  Sounds a bit apologetic. I don't think that the ecosystem decided. The language creators decided, and the ecosystem couldn't do much about it.
  - Cthulhu_ 3y ago
    Go's development process is fairly open and democratic though; if enough people flag it up, and if a case can be made for stack traces, it can be added. As it stands though, the consensus is that it doesn't add enough value, it's too expensive (cost/benefit), errors are normal program flow, and 3rd party libraries can add the functionality if one decides they need/want it in their application.
  - Xeoncross 3y ago
    I say ecosystem to mean the majority of packages. That's the ecosystem.
- eweise 3y ago
  "your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong." Curious how Go is better than other languages in this regard.
  - Cthulhu_ 3y ago
    That quote isn't about Go specifically though, but about general application design. It seems to be a subtle snipe that languages with stacktraces like Java, C# are too complicated or have too many layers ("lasagna code"), making them more difficult to debug.
tbarbugli 3y ago
we wrap all errors with a stack.Wrap function that adds stacktrace to the error. This allows us to add stacktraces to logs and err reporting tools like Sentry. Huge time saver

pipe01 3y ago

You can do it yourself if you want using `runtime.Stack` and a custom error type

minzi 3y ago
Embarrassingly, I’ve been writing Go for a while but never really thought about it. Now that it’s been mentioned I’m curious why this isn’t baked in by default for errors. Does anyone know?
- sapiogram 3y ago
  > I’ve been writing Go for a while but never really thought about it. Don't feel bad, I've tried to do this in some places, but I'm not sure it's worth it. It adds a ton of boilerplate to Go's already verbose error handling, since you need to wrap every error that gets returned from libraries.
- icholy 3y ago
  Creating stack traces is expensive.
  - tbarbugli 3y ago
    you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU
    - Cthulhu_ 3y ago
      That's still under the assumption that errors are exceptional, rare, and require a stacktrace to debug. But most errors are not exceptional and do not need debugging, like idk, a row not found error in a database. A crash, sure, that might need a stacktrace to debug. But that's already in place.
    - kbolino 3y ago
      Good error-wrapping discipline works better than stack traces, because not only do you have a trace of the calling context, you also have the values that caused the problem. Granted, a stack trace "always works", but it will never have the values of important variables.
      - Cthulhu_ 3y ago
        Now you mention it, a stack trace with function calls and all their arguments would be really powerful. But also expensive, ideally it would have zero overhead or only have the cost if you actually look at it / want to debug it.
        kbolino 3y ago
        One of the major optimizations is to pass function arguments in registers instead of on the stack. These registers might preserve their original values by the time you unwind the stack, but in many cases, probably won't. Preserving those values would lead to fewer available registers and/or more frequent register saving, which would create at least some overhead, even if you don't ever inspect it. There are probably lots of situations where it's worth it, though.
      - derekperkins 3y ago
        We do both and it works great
- closeparen 3y ago
  You’re supposed to prepend the context to an error before you return it, so the final error reads like a top-level stack trace: “handling request: fooing the bar: barring the baz: connecting to DB: timeout.”
- kbolino 3y ago
  Well, how would that work? Errors are just values. They don't have any special meaning nor is there any special ceremony to create them. A panic must start from calling panic(); there's no function or special statement to create or return an error. It might be possible to augment every `error`-typed return such that the concrete type is replaced by some synthetic type with a stack trace included. However, this would only work because `error` is an interface, so any function returning a concrete-typed error wouldn't be eligible for this; it would also add a lot of runtime overhead (including, at the very least, a check for nil on every return); and it would cause issues with code that still does == comparisons on errors. On the whole, I think error-wrapping solves the problem of tracing an error well enough as the language exists today. If errors are going to start having some magic added to them, I think the entirety of error-handling deserves a rethink (which may be due, to be fair).

Xeoncross 3y ago

Errors are different in every stdlib or 3rd party package I've ever used. The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong. I love stack traces in Java, but I don't miss them at all in Go.

the_gipsy 3y ago
Sounds a bit apologetic. I don't think that the ecosystem decided. The language creators decided, and the ecosystem couldn't do much about it.
- Cthulhu_ 3y ago
  Go's development process is fairly open and democratic though; if enough people flag it up, and if a case can be made for stack traces, it can be added. As it stands though, the consensus is that it doesn't add enough value, it's too expensive (cost/benefit), errors are normal program flow, and 3rd party libraries can add the functionality if one decides they need/want it in their application.
- Xeoncross 3y ago
  I say ecosystem to mean the majority of packages. That's the ecosystem.
eweise 3y ago
"your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong." Curious how Go is better than other languages in this regard.
- Cthulhu_ 3y ago
  That quote isn't about Go specifically though, but about general application design. It seems to be a subtle snipe that languages with stacktraces like Java, C# are too complicated or have too many layers ("lasagna code"), making them more difficult to debug.

tbarbugli 3y ago

we wrap all errors with a stack.Wrap function that adds stacktrace to the error. This allows us to add stacktraces to logs and err reporting tools like Sentry. Huge time saver