Comment by abvdasker | Hacker News Reader

Comment by abvdasker | Hacker News Reader

Parent Full thread

This is interesting, but I think it doesn't necessarily fit the language well.

1. Go has very few keywords relative to other newish languages like Swift and Kotlin. Introducing a new one should only be done if the benefits are undeniable.

2. It causes an early return without any use of the "return" keyword, which feels pretty weird.

3. It's a bit weird that err will be magically defined in a defer function if the surrounding function includes a "try". Does err have to be declared earlier in the function? If yes, it's strange that it seemingly never gets assigned. If there are multiple variables of type error in the function which one gets assigned the result of "try"?

4. Probably most importantly it doesn't feel very explicit. In some languages this may not be a problem, but Go is designed to be very explicit and this seems a bit incongruous with the rest the language's style.

Maybe I'm just not understanding the proposal. I do like how concise this is. It's nicely backwards compatible and allows existing error handling to stay the same.

For 3., For use in defer the error return does have to be declared as you'd expect, in the examples it's done in the function signature

  func CopyFile(src, dst string) (err error) {
                                  ^^^
                                  here

1. As explained in the proposal, try is not a keyword, but a built-in function.

2. Returning if there is an error is the whole point of this proposal.

3. I don't understand your point. Could you provide an example?

4. try is explicit. There is no implicit behavior or stack unwinding.

it uses the same syntax as functions, but it doesn't behave like a function – functions generally can't manipulate control flow like that. so calling it a function is weird because it's closer to a language construct like `await`

We already have one built-in function that alters the control flow: panic. But I agree it's a bit weird.

tbh i don't know Go too well. as i understand it, `panic` can indeed hijack the control flow, i.e. stop it. but any function¹ can do that: just do `while 1 {}`! control flow won't return to the caller either way. so it's not that weird after all

Ruby blocks can do non-local control flow, i.e. return from their surrounding function, but that's what makes them distinct from functions.

---

¹ in a turing-complete language

(i'm a Haskell enthusiast, so please excuse the nitpicking :)

A panic can be recovered with recover(), and thus the program can continue. While a function that does an infinite loop will halt the program and nothing else.

Reply on news.ycombinator.com