Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

language: Go 2: error handling meta issue #40432

ianlancetaylor opened this issue Jul 27, 2020 · 1 comment

language: Go 2: error handling meta issue #40432

ianlancetaylor opened this issue Jul 27, 2020 · 1 comment


Copy link

@ianlancetaylor ianlancetaylor commented Jul 27, 2020

This is a meta issue to summarize the current state of proposed changes to the Go language to improve error handling.

This issue is intended to be a summary to be updated from time to time. It is not intended for discussion of error handling in Go or ways to improve it. The intent is to provide an overview for people interested in changing the language. The issue exists as an acknowledgement that this is a common topic for Go 2 language changes. It does not mean that the language will actually change in any way. It may change, or it may not.

In August 2018 @rsc published a problem overview of error handling, including an introduction of a draft design that was not implemented. That problem overview lists the following goals:

  • For Go 2, we would like to make error checks more lightweight, reducing the amount of Go program text dedicated to error checking. We also want to make it more convenient to write error handling, raising the likelihood that programmers will take the time to do it.
  • Both error checks and error handling must remain explicit, meaning visible in the program text. We do not want to repeat the pitfalls of exception handling.
  • Existing code must keep working and remain as valid as it is today. Any changes must interoperate with existing code.

There have been many attempts to change the language to meet these goals. None have been accepted to date.

Many of the changes have been filed as Go 2 proposals, and can be found via the error-handling label. There has also been a great deal of discussion on various mailing lists, which we won't attempt to summarize here.

Some of the notable issues are (this list is not intended to be comprehensive):

  • The check/handle proposal.
    • There is a feedback page for this, including additional proposals.
    • One major reason this was rejected was a lack of clarity between handle and defer.
    • There are variants with named handlers, such as #27519 and #31743.
  • The try proposal.
    • A partial comment analysis.
    • One major reason this was rejected was the additional flow control: a complex expression using try could cause the function to return. Go currently has no flow control constructs at the expression level, other than panic which does more than just return from a function.
  • Special characters, often ! or ?, that insert an error check in a function call or assignment.
    • Proposed many times with variations, including but not limited to: #21155, #25273, #32500, #32884, #33074, #33150.
    • These are typically rejected because they are cryptic. Often a single ! or other character leads to a change in flow control.
  • Simplifications of if err != nil, to reduce boilerplate.
    • Proposed many times with variations, including but not limited to: #27567, #28329, #32611, #32845, #32946.
    • These are typically rejected either because they don't reduce the boilerplate enough to make it worth changing the language, or because they are cryptic.
@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Jul 27, 2020
@golang golang locked and limited conversation to collaborators Jul 27, 2020
@golang golang deleted a comment from tdakkota Jul 27, 2020
Copy link
Contributor Author

@ianlancetaylor ianlancetaylor commented Nov 26, 2020

There is another categorization of error handling proposals at


Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant