Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discussion: Reduce error handling boilerplate in Golang using '?'

github.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#41

Post by nonethewiser »

chairhairair wrote: post #29
floating-io wrote: post #19

The 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.

I tend to agree that ? looks like "if then" when what we really want is some sort of coalescing, or "if not then".

foo ?? { bar }

foo ?/ { bar }

foo ?: { bar }

foo ?> { bar }

foo ||> { bar }

Im not sure I like the idea at all though. It seems like a hack around a pretty explicit design choice. Although I do tend to agree the error handling boilerplate is kind of annoying.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#42

Post by zimbatm »

This change would mark a turn in the language's evolution, as it would be the first implicit variable to be added to the language.

I'm not going to invoke the slippery slope argument, but what distinguishes Go from the pack is how explicit it is. It can make it more tedious to write, but also much easier to follow as a reader.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#43

Post by nonethewiser »

jayd16 wrote: post #34
floating-io wrote: post #19

The 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 }

This is probably the one that would anger Golangers the most lol

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#44

Post by zemo »

zimbatm wrote: post #42

This change would mark a turn in the language's evolution, as it would be the first implicit variable to be added to the language. I'm not going to invoke the slippery slope argument, but what distinguishes Go from the pack is how explicit it is. It can make it more tedious to write, but also much easier to follow as a reader.

there's some precedent in the direction of adding predeclared identifiers for error handling: the identifier `error` was originally not predeclared, you had to import it from `io` (or maybe `os`?) and refer to it as `io.Error` everywhere.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#45

Post by nonethewiser »

madeofpalk wrote: post #16
teeray wrote: post #4

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. 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.

Im not really following this. Only somewhat familiar with Go.

The pattern we're talking about is returning errors and having to explicitly check for them, right? How does the lack of "algebraic data types/enum/unions" make this pattern un-ergonomic?

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#46

Post by pjmlp »

zimbatm wrote: post #42

This change would mark a turn in the language's evolution, as it would be the first implicit variable to be added to the language. I'm not going to invoke the slippery slope argument, but what distinguishes Go from the pack is how explicit it is. It can make it more tedious to write, but also much easier to follow as a reader.

It is not more explicit than C, Pascal, JOVIAL and many other predating it for decades.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#47

Post by zemo »

floating-io wrote: post #19

The 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…

Go doesn't have a ? operator today, and the ? operator being used for error handling has precedence in Rust and Zig, so it doesn't seem to be all that out of the ordinary or without precedent in other languages.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#48

Post by pjmlp »

teeray wrote: post #30
richbell wrote: post #18

Earlier 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 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.

Traditionally linters are workarounds for features that should be in the language.

Instead we pack best practices in an external tool.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#49

Post by nonethewiser »

Swizec wrote: post #8
teeray wrote: post #4

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. 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…

Yes, same experience. As someone who learned on python then got deep into Typsecript, this was a major bummer when returning to python.

Its funny because when I was a beginner in both I strongly preferred python syntax. I thought it was much simpler.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#50

Post by 827a »

reactordev wrote: post #40

This 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 .

For clarity: The author is Ian Lance Taylor. He's a principal engineer at Google, on the Golang team, and the 4th largest contributor to the language. The personal attack on him not understanding the implications of the proposal is a bit cringe.
Post reply on HN