The Go language will not be adding a "try" keyword in the next major version, despite this being a major part of what was proposed for version 1.14.
Go, an open source language developed by Google, features static typing and native code compilation. It is around the 15th most popular language according to the Redmonk rankings.
Error handling in Go is currently based on using if statements to compare a returned error value to nil. If it is nil, no error occurred. This requires developers to write a lot of if statements.
"In general Go programs have too much code-checking errors and not enough code handling them," wrote Google principal engineer Russ Cox in an overview of the error-handling problem in Go.
A try statement was proposed to help reduce the coding burden. Upon further reflection:
That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post yesterday.
[...] “Making an exit point of a function that isn't a return, and is meant to be commonplace, may lead to much less readable code,” said one user.
The outcome is a good one insofar as the Go community has proved able to make and withdraw a major proposal without rancour. And as for error handling, no doubt the team will, um, try again.
(Score: 3, Insightful) by Thexalon on Wednesday July 17 2019, @07:17PM (1 child)
The main upside of a "break" is to short-circuit when possible, but you're right that it's frequently unnecessary.
One refactor that also eliminates "break", especially with multiple layers, is an early "return", combined with making the inside of a block into a method. Or in pseudocode, this:
becomes this:
It's up to you whether that's better, although I generally think it is.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Thursday July 18 2019, @05:59AM
I usually use the nested function method. It works fine if the outer loop isn't time sensitive or the language and compiler have decent inline function support, but even then if the innermost loop needs access to the outermost loop's then other methods need to be used.