5 ms·

More like "Endless Error Handling Blog Posts". For all the big talk about how horrible the error handling is, it's really not a big deal in my day-to-day (havin

More like "Endless Error Handling Blog Posts". For all the big talk about how horrible the error handling is, it's really not a big deal in my day-to-day (having written Go code pretty regularly for over six years now). For instance, if you have a function that does multiple things in sequence, how common is it to reorder the individual steps? Most times you have an intrinsic ordering between each step. And even if you reorder at some point, flipping some ":=" into "=" or vice versa based on compiler errors is not as big of a deal as the author makes it out to be.

grenoire 5y ago
I don't agree to the := and = issue, I think it's really bothersome primarily for the reasons that the author highlights. Unpacking is indeed inconsistent with its conditional bypasses on the := double-assignment checks. The committee's resistance against syntactic sugar like ? on this is also bothersome.
- janekm 5y ago
  I hadn't looked at go for a few years but := is terrible for several other reasons too: - small difference in visible syntax (easy to miss) - less clear than explicit var - most crucially, can't be used for const declarations but in most cases where it's used (including the blog post) const should have been used (return from a called function that won't be modified by the caller).
  - Andys 5y ago
    Ironically, "easy to miss" is my objection about Rust's "?" suffix
    - janekm 5y ago
      It's a fair point (and the same objection could be made to Swift's ! and ?). Over time I have given up my objections to verboseness... Clarity of code is far more important than conciseness. I do see the point for some syntactic sugar for error handling though, long if chains are terrible for clarity as well. And arguably ? and ! are typographic symbols our brains are well trained to spot.
lm28469 5y ago
Yeah it's really not an issue irl. It feels a bit weird at first but that's just how it is and you learn to design with it, it's not a deal breaker by any stretch of the imagination. People have been talking about it forever because it's "how to shit on golang 101"
- simiones 5y ago
  > you learn to design with it There is nothing to learn - it's an ugly wart you have to accept if you're using the language. There's no going around the fact that it's verbose, error-prone, and makes code hard to read and review.
  - rob74 5y ago
    ...as opposed to error handling with exceptions, which is not error-prone at all and makes code really easy to review (or rather, it make it easy to get a false sense of security, and months later you find out that there is an exception you forgot to handle).
  - thiht 5y ago
    > error-prone, and makes code hard to read and review. Strong disagree on that. The fact that it’s explicit makes it extremely easy to reason about and Go code reviews are a breathe. It’s verbose, I’ll give you that, but the rest doesn’t hold.
    - samhw 5y ago
      It's true that explicit code is good, but "Go code reviews are a breeze" was not remotely my experience. For me and my past teams, reading through piles of boilerplate verbiage like this - among other 'explicit' syntax - was more of an impediment to understanding the flow of the program. Personally I think what the above commenter said is pretty much spot-on, and typical of Go teams I worked in.
      - lm28469 5y ago
        > my experience. > For me and my past teams > piles of boilerplate verbiage like this I'd love to have a look at your code because this isn't my experience at all. What's your background ? What's your team background ? Are you writing go code with the mindset of a java/cpp/whatever dev ? Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
onionisafruit 5y ago
When I was new to go I would have written one of these blog posts if I blogged. Over time I’ve come to appreciate go’s approach to errors. Nowadays I find it nerve wracking to write Ruby (my old daily driver). I would still like to find some way to make go’s error handling a little easier on the eyes, but I’ll take this over having to be constantly vigilant about handling every possible exception.
kybernetikos 5y ago
Personally I think this is a massive footgun, at least somewhat affected by ordering: https://play.golang.org/p/oHFobaOexwR https://play.golang.org/p/oHFobaOexwR Of course, I know now that I was 'holding it wrong'.

grenoire 5y ago

I don't agree to the := and = issue, I think it's really bothersome primarily for the reasons that the author highlights. Unpacking is indeed inconsistent with its conditional bypasses on the := double-assignment checks. The committee's resistance against syntactic sugar like ? on this is also bothersome.

janekm 5y ago
I hadn't looked at go for a few years but := is terrible for several other reasons too: - small difference in visible syntax (easy to miss) - less clear than explicit var - most crucially, can't be used for const declarations but in most cases where it's used (including the blog post) const should have been used (return from a called function that won't be modified by the caller).
- Andys 5y ago
  Ironically, "easy to miss" is my objection about Rust's "?" suffix
  - janekm 5y ago
    It's a fair point (and the same objection could be made to Swift's ! and ?). Over time I have given up my objections to verboseness... Clarity of code is far more important than conciseness. I do see the point for some syntactic sugar for error handling though, long if chains are terrible for clarity as well. And arguably ? and ! are typographic symbols our brains are well trained to spot.

lm28469 5y ago

Yeah it's really not an issue irl. It feels a bit weird at first but that's just how it is and you learn to design with it, it's not a deal breaker by any stretch of the imagination. People have been talking about it forever because it's "how to shit on golang 101"

simiones 5y ago
> you learn to design with it There is nothing to learn - it's an ugly wart you have to accept if you're using the language. There's no going around the fact that it's verbose, error-prone, and makes code hard to read and review.
- rob74 5y ago
  ...as opposed to error handling with exceptions, which is not error-prone at all and makes code really easy to review (or rather, it make it easy to get a false sense of security, and months later you find out that there is an exception you forgot to handle).
- thiht 5y ago
  > error-prone, and makes code hard to read and review. Strong disagree on that. The fact that it’s explicit makes it extremely easy to reason about and Go code reviews are a breathe. It’s verbose, I’ll give you that, but the rest doesn’t hold.
  - samhw 5y ago
    It's true that explicit code is good, but "Go code reviews are a breeze" was not remotely my experience. For me and my past teams, reading through piles of boilerplate verbiage like this - among other 'explicit' syntax - was more of an impediment to understanding the flow of the program. Personally I think what the above commenter said is pretty much spot-on, and typical of Go teams I worked in.
    - lm28469 5y ago
      > my experience. > For me and my past teams > piles of boilerplate verbiage like this I'd love to have a look at your code because this isn't my experience at all. What's your background ? What's your team background ? Are you writing go code with the mindset of a java/cpp/whatever dev ? Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done

onionisafruit 5y ago

When I was new to go I would have written one of these blog posts if I blogged. Over time I’ve come to appreciate go’s approach to errors. Nowadays I find it nerve wracking to write Ruby (my old daily driver). I would still like to find some way to make go’s error handling a little easier on the eyes, but I’ll take this over having to be constantly vigilant about handling every possible exception.

kybernetikos 5y ago

Personally I think this is a massive footgun, at least somewhat affected by ordering: https://play.golang.org/p/oHFobaOexwR https://play.golang.org/p/oHFobaOexwR Of course, I know now that I was 'holding it wrong'.