honestly with copilot and friends this is not really an issue
Discussion: Reduce error handling boilerplate in Golang using '?'
21–30 of 94 posts
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#22I 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 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. This implies that th…
> You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake.
While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#23Earlier quoted context omitted.
> I 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. This implies that th…
> You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake. While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?
> While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?
This isn't foolproof. If you're calling multiple methods and reusing `err` it won't give an error because it's technically not unused.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#24(I'm not a Go programmer) I find this a bit odd. Isn't the idea of the primitive error handling that it is obvious and easy, as in "functions can return multiple results, a popular pattern is to return the good result and the error as two separate nullable values of which exactly one will be not null, so you can check if err == nil."? If you go with fancy error handling anyway, how is this '?' better than returning a…
The ? syntax agrees that errors should just be regular values returned from functions, and handling of errors should be locally explicit. It's not a different approach from `if err != nil return err`, it merely codifies the existing practice, and makes expressing the most common cases more convenient and clearer. It's clearer because when you see ? you know it's returning the error in the standard way, and it can't b…
I think what I meant is that out of these three ways to do it, I don't like the second one:
1. The language has the feature of returning multiple values, which is then used in an error handling pattern.
2. The proposal is about special syntax for that pattern
3. Languages that have generics (like Go) can instead implement a Result type, turning this pattern into more readable code without the extra syntax.
I feel like a Result type would have more advantages and be less disruptive than a syntax macro for a pattern, but I'm not sure.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#25I 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 appreciate verbose and explicit patterns like this, but what go lacks is the algebraic data types/enum/unions to actually make this more ergonomic and checked. I find it bizzare that go so strongly relies on this pattern, but lacks the features to make sure you actually check for errors.
100% this. The idea is ok, the tooling to actually use it is terrible
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#26This is from Ian Lance Taylor, a major figure in the development of Go. Taylor was instrumental in bringing generics to the language, this proposal is worth taking seriously.
> Taylor was instrumental in bringing generics to the language, this proposal is worth taking seriously. He submitted, what, 8 failed generics proposals before Phil Wadler came in to figure out what he was missing? I don't mean to diminish what he has done. He is clearly an important contributor and even those failed proposals were important steps along the way. What I do mean is that judging a proposal based on who…
It's worth noting that 'taking a proposal seriously' doesn't equate to accepting it.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#27Error handling is really not an issue that needs fixing in Golang. That being said, I wish Golang had an assert key word as a shortcut to "if cond { panic }". A lot of those "if err != nil" in the wild should really just be assertions.
There are 0 times I’d want to panic in go code in production services.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#28The proposal confuses shadowing of err, which is mostly irrelevant anyway but at least you can see it today. It also makes breakpoints or inserting log statements etc. more difficult without reformatting code. And lastly, it teases the ternary conditional operator that Go lacks, constantly reminding me of this. So IMO I would use a different language rather than adopt this.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#29The 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…
It could be:
foo ?! { bar }
But, now we’re potentially confusing the “negation” and the “exclamation” meanings the bang symbol usually tries to communicate.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#30I 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 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. This implies that th…
> You are never forced to check errors…
There are linters that do, and I am of the opinion they should be added to `go vet`.
> Knowing the operation can be faulty somehow is a good way of putting it, because in most cases it's difficult — if not impossible
Guru was once able to tell you exactly what errors could be generated from any given err. Now that the world is LSP, we have lost this superpower.