6 ms·

The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions. I think I'd be disappoi

The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions. I think I'd be disappointed if Try/Catch ever made their way into the language.

progbits 3y ago
Error handling != exceptions. Step one would bee sum types, so only valid value space can be represented (return value or error, but not both or neither).
- jmarchello 3y ago
  Good point, a poor assumption on my part
- wizhi 3y ago
  What would be the big gain from this, over the existing approach using multiple return values?
geodel 3y ago
I am not demanding either of these things. Just making general comment based on observing folks.
dinkleberg 3y ago
Yeah I have to agree that the Go-style error handling does actually lead to better code. At least when I write it. It makes me think through how I am going to handle error states rather than chucking it in try/except in Python and hoping nothing breaks lol.
- deleted 3y ago
  [deleted]
- jen20 3y ago
  Rust-style error handling works better though - similar to Go, but with the addition of enums such that the precise types of errors which may be encountered can be easily documented in the type system.
  - dinkleberg 3y ago
    Agreed, I’d love if they would take inspiration from Rust and bring that to Go.
    - jen20 3y ago
      Yes - if Go had sum types (and they were idiomatically used in the standard library), it would take it from a pretty good platform to a first class one. The library ecosystem is already excellent, and the tooling is good, lack of sum types is the single wart that makes me regret it every time I pick Go up for a project.
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=...
dragonwriter 3y ago
Try/catch/finally is in the language, its just called panic/defer/recover, where panic works like throw, every function works like try, defer works like a combination of a nonselective catch that rethrows by default and finally, and recover disables the rethrows-by-default behavior, while also being the only way to interrogate the panic to see if you should do that.

progbits 3y ago

Error handling != exceptions. Step one would bee sum types, so only valid value space can be represented (return value or error, but not both or neither).

jmarchello 3y ago
Good point, a poor assumption on my part
wizhi 3y ago
What would be the big gain from this, over the existing approach using multiple return values?

geodel 3y ago

I am not demanding either of these things. Just making general comment based on observing folks.

dinkleberg 3y ago

Yeah I have to agree that the Go-style error handling does actually lead to better code. At least when I write it. It makes me think through how I am going to handle error states rather than chucking it in try/except in Python and hoping nothing breaks lol.

deleted 3y ago
[deleted]
jen20 3y ago
Rust-style error handling works better though - similar to Go, but with the addition of enums such that the precise types of errors which may be encountered can be easily documented in the type system.
- dinkleberg 3y ago
  Agreed, I’d love if they would take inspiration from Rust and bring that to Go.
  - jen20 3y ago
    Yes - if Go had sum types (and they were idiomatically used in the standard library), it would take it from a pretty good platform to a first class one. The library ecosystem is already excellent, and the tooling is good, lack of sum types is the single wart that makes me regret it every time I pick Go up for a project.

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=...

dragonwriter 3y ago

Try/catch/finally is in the language, its just called panic/defer/recover, where panic works like throw, every function works like try, defer works like a combination of a nonselective catch that rethrows by default and finally, and recover disables the rethrows-by-default behavior, while also being the only way to interrogate the panic to see if you should do that.