Google's Go team decides not to give it a try
A key proposal for Go 1.14 – adding a built-in try keyword – has been declined
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
"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.
There was therefore a proposal to add a built-in
try function which lets you eliminate many of the
if statements and triggers a return from a function if an error is detected. The proposal was not for full exception handling, which is already present in Go via the
That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post yesterday.
Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule. As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.
More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.
What was the problem with
try? Opinions in the Go community are mixed, but what emerged is that many Go programmers do not mind the current approach, and did not like introducing a new built-in function that alters the control flow.
“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.
You can't say Go without Google – specifically, our little logo, Chocolate Factory insistsREAD MORE
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.®