4 ms·

I hope the next big thing is a proper error handling instead of if-hell.

by zerr 5y ago

lowmagnet 5y ago
This is the biggest complaint after generics, and there are a few proposals to dynamically resolve it in either libraries or language features. These proposals are in the go2drafts section, but keep in mind that this is where generics were originally placed on the timeline. Yet here we are with a backward-compatible change to the language in the sub-2.0 version of the language.
5e92cb50239222b 5y ago
Give it 20 more years of evolution (considering we're talking about Go, probably 70 years), and we get another C++. A Google of the future (let's call it Scroogle) starts another language that can be used by recent graduates that have no idea about what they're doing to write mountains of JSON fiddling boilerplate. Rinse and repeat.
- nauticacom 5y ago
  Hey, don't be so pessimistic. We'll probably have another serialization protocol by then.
Cthulhu_ 5y ago
There was a spurt of this before they seriously went to work on generics, and the conclusion was "actually, it's fine the way it is". There's huge discussions on the matter as well as various proposals, but they all came with caveats that, in the end, weren't considered a significant improvement. That said, with generics, it should be possible to change to the 'Either' style [0] of error handling. And with another compiler feature to be added, er, 'exhaustive switch/case' or whatever you want to call it, they can make it a compiler error to not handle the error case. That said, I don't see the language developers or community making it a standard anytime soon. The current style of error handling doesn't hurt enough. It's verbose and repetitive, sure, but if the alternative is something clever or magic, it's not the way to go. [0] https://www.scala-lang.org/api/2.13.6/scala/util/Either.html https://www.scala-lang.org/api/2.13.6/scala/util/Either.html
ernst_klim 5y ago
I think people are constantly focusing on the wrong target here though. The main problem of error handling in Go is not the tediousness of writing if err != nil {} after each function (it's not nice but bearable). The main problem is how hard to actually process errors. In Go, there are three types of errors: custom structs with contextual info, predefined error constants of type stringError aka sentinels, and wrapped stringErrors, produced in-place by fmt.Errorf. The first ones can be matched by type coersion or errors.As function. The second ones can be compared with == operator. The last ones can be either parsed by regex, or matched by the error they wrap and then unwrapped. Oh, and the signature is nearly always just error, so basically to process errors gracefully you have to read the docs for each function instead of just looking at the signature. It's so extremely inconvenient and tedious so nearly nobody process errors in Go, despite what language creators say. People either return error to the top of the callstack, maybe wrapping it in additional string, thus emulating poor man's exceptions without stack traces, or panic in-place. Nearly nobody catches and matches errors, as many in C++, Java, Scala or OCaml|Haskell world do.
- _j_jonas_2231 5y ago
  Exactly. My experience and opinion as well, but better explained that I could have. My IDE helps a lot the typing of the error conditions and is collapsing it nicely. This is not the problem, but the error handling.

I hope the next big thing is a proper error handling instead of if-hell.

by zerr 5y ago

I hope the next big thing is a proper error handling instead of if-hell.

This is the biggest complaint after generics, and there are a few proposals to dynamically resolve it in either libraries or language features. These proposals are in the go2drafts section, but keep in mind that this is where generics were originally placed on the timeline. Yet here we are with a backward-compatible change to the language in the sub-2.0 version of the language.

5e92cb50239222b 5y ago

Give it 20 more years of evolution (considering we're talking about Go, probably 70 years), and we get another C++. A Google of the future (let's call it Scroogle) starts another language that can be used by recent graduates that have no idea about what they're doing to write mountains of JSON fiddling boilerplate. Rinse and repeat.

nauticacom 5y ago
Hey, don't be so pessimistic. We'll probably have another serialization protocol by then.

Cthulhu_ 5y ago

There was a spurt of this before they seriously went to work on generics, and the conclusion was "actually, it's fine the way it is". There's huge discussions on the matter as well as various proposals, but they all came with caveats that, in the end, weren't considered a significant improvement. That said, with generics, it should be possible to change to the 'Either' style [0] of error handling. And with another compiler feature to be added, er, 'exhaustive switch/case' or whatever you want to call it, they can make it a compiler error to not handle the error case. That said, I don't see the language developers or community making it a standard anytime soon. The current style of error handling doesn't hurt enough. It's verbose and repetitive, sure, but if the alternative is something clever or magic, it's not the way to go. [0] https://www.scala-lang.org/api/2.13.6/scala/util/Either.html https://www.scala-lang.org/api/2.13.6/scala/util/Either.html

ernst_klim 5y ago

I think people are constantly focusing on the wrong target here though. The main problem of error handling in Go is not the tediousness of writing if err != nil {} after each function (it's not nice but bearable). The main problem is how hard to actually process errors. In Go, there are three types of errors: custom structs with contextual info, predefined error constants of type stringError aka sentinels, and wrapped stringErrors, produced in-place by fmt.Errorf. The first ones can be matched by type coersion or errors.As function. The second ones can be compared with == operator. The last ones can be either parsed by regex, or matched by the error they wrap and then unwrapped. Oh, and the signature is nearly always just error, so basically to process errors gracefully you have to read the docs for each function instead of just looking at the signature. It's so extremely inconvenient and tedious so nearly nobody process errors in Go, despite what language creators say. People either return error to the top of the callstack, maybe wrapping it in additional string, thus emulating poor man's exceptions without stack traces, or panic in-place. Nearly nobody catches and matches errors, as many in C++, Java, Scala or OCaml|Haskell world do.

_j_jonas_2231 5y ago
Exactly. My experience and opinion as well, but better explained that I could have. My IDE helps a lot the typing of the error conditions and is collapsing it nicely. This is not the problem, but the error handling.