Discussion: Reduce error handling boilerplate in Golang using '?'
1–10 of 94 posts
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#2This 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.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#3(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 Result and do something like foo().getOr { return fmt.Errorf("Tja: %v", err) }
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#4I 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 the language for awhile, you begin to dislike the elaborate system of rugs other languages have to sweep errors under. Errors in Go are right there, in your face, and undeniable that the operation you are doing can be faulty somehow. With good error wrapping, you can trace down exactly which of these `if err != nil` blocks generated the error without a stack trace. If it bothers you that much, you can always make a snippet / macro for it in your editor.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#5It saddens me tbat the default error handler is "return err", as opposed to something that appends context/stack trace.
We've converted a few scripts and webapps from Python to Go, and if one does default handling ("return err") the error logs became significantly less useful, compared to exception backtraces. Yes, there are ways around it, but most tutorials don't show them.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#65 years ago I would be more sympathetic to this proposal.
But now we have LLM copilots, so writing boilerplate in any language is dramatically more optional.
And I don't see this proposal significantly improving readability of the code.
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#7I 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…
Super interested in your approach to error wrapping! It’s a feature I haven’t used much.
I tend to use logs with line numbers to point to where errors occur (but that only gets me so far if I’m returning the error from a child function in the call stack.)
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#8I 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…
Where I've found `?` super helpful in JS/TS and now miss it the most in Python is dealing with nested data structures.
``` if (foo.bar?.baz?.[5]?.bazinga?.value) ```
Is so much nicer than
``` if foo.bar and foo.bar.baz and foo.bar.baz[5] and foo.bar.baz[5].bazinga and foo.bar.baz[5].bazinga.value ```
I honestly don't care which one of those is falsy, my logic is the same either way.
This enables you to ergonomically pass around meaningful domain-oriented objects, which is nice.
Edit: looks like optional chaining is a separate proposal – https://github.com/golang/go/issues/42847
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#9My knee jerk reaction is that introducing even more ways to write the same thing is going to slowly bloat the language, but Go does it infrequently enough that it doesn't seem like it's going to become a huge problem. I think I could get used to this syntax.
> Disadvantage 4: No other block in Go is optional. The semicolon insertion rule, and the fact that a block is permitted where a statement is permitted, means that inserting or removing a newline can convert one valid Go program into another. As far as I know, that is not true today.
Yeah, this seems like a big problem to me, personally. Go has a fair number of lingering foot guns but this is one too far IMO. I think the no-block case should require something else to follow it, perhaps the return keyword. That'd also help prevent it from being as easily missed...
Re: Discussion: Reduce error handling boilerplate in Golang using '?'
#10I 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.