It is crazy that error handling is one of the most important things, yet even modern languages suck at it.
In my opinion everything should return type like MayFail, Result
Discussion: Reduce error handling boilerplate in Golang using '?'
31–40 of 94 posts
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#32I vote no on this proposal.
Go error handling should remain simple, like the language.
These are all tools, just pick the one you like and stop trying to make them like others.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#33I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…
I am but one lowly data point, but I've been using Go for a long time and the pervasive `if err != nil` is one of my least favorite parts of the language.
Yeah I've been using Go for years at multiple companies and I agree. Using multiple lines of code for something that's so common just isn't an efficient use of screen space to me and at a certain point all those lines hurt readability of code.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#34The biggest issue I have with this proposal is that reading the code in naïve fashion comes up with the wrong answer for me; YMMV. The proposed form-- foo ? { bar } Reads naturally to me as "If foo then bar", when it's actually "If foo's error return exists then bar". I would suggest a different operator character, because this one reads wrongly IMO. Maybe it's just because I originally come from C, where `foo ? bar…
How about this? :)
{ foo } catch { bar }Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#35I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…
I am but one lowly data point, but I've been using Go for a long time and the pervasive `if err != nil` is one of my least favorite parts of the language.
Big same.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#36I vote no on this proposal. Go error handling should remain simple, like the language. These are all tools, just pick the one you like and stop trying to make them like others.
> These are all tools, just pick the one you like and stop trying to make them like others.
I'm not so sure I agree with that. I'm glad Rust continues to evolve at a healthy pace and pick up new syntactic features.
Boilerplate is a sin against the brain. As long as you don't pay it down with increased cognitive complexity, it should be eliminated at all costs.
Error handling is such an essential feature of problem solving that this should be one of the highest priorities for a language to get right. It should be so simple and elegant that you can bash it out in a few tokens, and almost impossible to get wrong.
I think Go would be a much better language if it took this to task. I reach for Rust for out of domain problems because it's so expressive and intentional and safe and concise.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#37I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…
I'm not a Go programmer, but I feel like I've sort of "grown up" around them as the language has evolved. for a while I thought that the `if err != nil { ... }` was silly to put everywhere. As I've grown and written a lot more code, however, I actually don't see a problem with it. I'd even go as far as to say that it's a good thing because you're acknowledging the detail that an error could have occurred here, and you're explicitly choosing to pass the handling of it up the chain. with exceptions, there can be a lot of hidden behavior that you're just sweeping under the rug, or errors happen that you didn't even think could be raised by a function.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#38I vote no on this proposal. Go error handling should remain simple, like the language. These are all tools, just pick the one you like and stop trying to make them like others.
By that logic, Go shouldn't have generics but they've added a lot of value to our codebase.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#39I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…
I mostly agree but I wish it could be more automatic. I like Golang's error system I just wish they'd provide shorthand ways of handling them.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#40This breaks go's readability and explicit nature. No thanks. The author doesn't understand the implications of the proposal. What if the args are in a different order returned? "foo, error" or "error, *foo" ? - I've seen many permutations of this. Being explicit about error handling is actually a good thing.