5 ms·

Great, so Go has support for native stacktraces so bubbled errors don't get shadowed? Just because Go made opinionated design decisions around their error hand

by kromem 3y ago

Great, so Go has support for native stacktraces so bubbled errors don't get shadowed? Just because Go made opinionated design decisions around their error handling a decade ago when developing the language doesn't mean that there's not practical room for improvement as the language is widely in production and shortcomings in its error handling have been found. The number of hacks I've seen over the years to try and solve the "wait, where did this error originate" problem in Go are legion, with little standardization. And no, using Errorf with '%w' to wrap error messages along the stack isn't exactly an elegant solution. Even if they want to keep the core error behavior as it is for compatibility, providing a core library way of wrapping with stacktraces would be a very useful next step, particularly given the most popular package doing that previously is now unmaintained.

philosopher1234 3y ago
>And no, using Errorf with '%w' to wrap error messages along the stack isn't exactly an elegant solution. I don't think anyone has ever claimed otherwise. But I do think its a pretty good solution. Whats elegance worth, anyways?
randomdata 3y ago
> providing a core library way of wrapping with stacktraces would be a very useful next step What eventually became the standard library error wrapping proposal evolved from the work done on the Upspin project. It did include stacktraces, and believed like you that it would be useful to have them. But analysis of the data showed that nobody ever really used them in practice and, for that reason, was removed from the final proposal. > particularly given the most popular package doing that previously is now unmaintained. Lacking wide appeal doesn't mean there isn't a niche need, of course. However, with the standard library accepting a standard for error wrapping, which this package you speak of has been updated to be compatible with, what further maintenance would be needed, exactly? It would be more concerning if it wasn't considered finished by now. It seems the solution for niche needs is right there.
- physicles 3y ago
  In the last few months I've realized what I desperately need: a way to wrap an error with a call stack at the point where it enters our code base. This would probably save me on average 20-30 minutes a week. I see this all the time: main.go:141 error: could not transmogrify the thing: a144cd21c48 And then I literally grep the code base to find the error message. That works ~50% of the time, but the other 50%, I see this: main.go:141 error: not found And then I have to spend 5-10 minutes spelunking to try to find where that error might have originated from. But this would be amazing: main.go:141 error: not found callstack=...
  - tombh 3y ago
    This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!? Have you seen https://github.com/tomarrell/wrapcheck https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics. But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.
    - randomdata 3y ago
      I find it interesting how, as soon as the word error shows up, people seemingly forget how to program. Ignore the word error for a moment. Think about how you program in the general case, for a hypothetical type T. What is it that you do to to your T values to ensure that you don't have the same problem? Now do that same thing when T is of the type error. There is nothing special about errors.
  - kitd 3y ago
    Agreed. In fact I wrote a (very) small library to help deal with it. https://github.com/kitd/chock https://github.com/kitd/chock

by kromem 3y ago

philosopher1234 3y ago

>And no, using Errorf with '%w' to wrap error messages along the stack isn't exactly an elegant solution. I don't think anyone has ever claimed otherwise. But I do think its a pretty good solution. Whats elegance worth, anyways?

randomdata 3y ago

> providing a core library way of wrapping with stacktraces would be a very useful next step What eventually became the standard library error wrapping proposal evolved from the work done on the Upspin project. It did include stacktraces, and believed like you that it would be useful to have them. But analysis of the data showed that nobody ever really used them in practice and, for that reason, was removed from the final proposal. > particularly given the most popular package doing that previously is now unmaintained. Lacking wide appeal doesn't mean there isn't a niche need, of course. However, with the standard library accepting a standard for error wrapping, which this package you speak of has been updated to be compatible with, what further maintenance would be needed, exactly? It would be more concerning if it wasn't considered finished by now. It seems the solution for niche needs is right there.

physicles 3y ago
In the last few months I've realized what I desperately need: a way to wrap an error with a call stack at the point where it enters our code base. This would probably save me on average 20-30 minutes a week. I see this all the time: main.go:141 error: could not transmogrify the thing: a144cd21c48 And then I literally grep the code base to find the error message. That works ~50% of the time, but the other 50%, I see this: main.go:141 error: not found And then I have to spend 5-10 minutes spelunking to try to find where that error might have originated from. But this would be amazing: main.go:141 error: not found callstack=...
- tombh 3y ago
  This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!? Have you seen https://github.com/tomarrell/wrapcheck https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics. But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.
  - randomdata 3y ago
    I find it interesting how, as soon as the word error shows up, people seemingly forget how to program. Ignore the word error for a moment. Think about how you program in the general case, for a hypothetical type T. What is it that you do to to your T values to ensure that you don't have the same problem? Now do that same thing when T is of the type error. There is nothing special about errors.
- kitd 3y ago
  Agreed. In fact I wrote a (very) small library to help deal with it. https://github.com/kitd/chock https://github.com/kitd/chock