Re:Proposal: A built-in Go error check function, try
by Alexendoo on Wednesday June 05, 2019 @06:55AM
(#20103082)
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
Re:Proposal: A built-in Go error check function, try
by ngrilly on Wednesday June 05, 2019 @03:54AM
(#20102340)
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.
Re:Proposal: A built-in Go error check function, try
by uryga on Wednesday June 05, 2019 @10:13AM
(#20104539)
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`
Re:Proposal: A built-in Go error check function, try
by ngrilly on Wednesday June 05, 2019 @10:47AM
(#20104934)
We already have one built-in function that alters the control flow: panic. But I agree it's a bit weird.
Re:Proposal: A built-in Go error check function, try
by uryga on Wednesday June 05, 2019 @06:32PM
(#20109805)
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 :)
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.