In go you can call, debug.Stack() at any time to get a stack trace. And it’s trivial to build error handling wrappers that can do this for on logging of an error.
You will get the stack at the point of your ‘debug.Stack()’ call though, not where the error happened.
I’m leaning go, and starting to get used to it, but the error handling is just obnoxious. The constant “if err != nil” makes reading the actual logic so much harder. I’m surprised they haven’t come up with some syntactical sugar to make it simpler yet, but these devs seem to see it as some sort of “badge of honor” to suffer.
It will be where the error happened if you conventionally pass your errors to a logger that then prints the stack trace, which is virtually what Python et. al. are doing anyway.
Go is not a language I’m a huge fan of tbh, but this mild inconvenience is not one of the things I would criticise it for. What you’re describing w.r.t control flow for errors absolutely is though.
In go you can call,
debug.Stack()at any time to get a stack trace. And it’s trivial to build error handling wrappers that can do this for on logging of an error.You will get the stack at the point of your ‘debug.Stack()’ call though, not where the error happened.
I’m leaning go, and starting to get used to it, but the error handling is just obnoxious. The constant “if err != nil” makes reading the actual logic so much harder. I’m surprised they haven’t come up with some syntactical sugar to make it simpler yet, but these devs seem to see it as some sort of “badge of honor” to suffer.
It will be where the error happened if you conventionally pass your errors to a logger that then prints the stack trace, which is virtually what Python et. al. are doing anyway.
Go is not a language I’m a huge fan of tbh, but this mild inconvenience is not one of the things I would criticise it for. What you’re describing w.r.t control flow for errors absolutely is though.