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

spec: error handling meta issue #40432

Open
ianlancetaylor opened this issue Jul 27, 2020 · 1 comment
Open

spec: error handling meta issue #40432

ianlancetaylor opened this issue Jul 27, 2020 · 1 comment
Labels
error-handling Language & library change proposals that are about error handling. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. umbrella
Milestone

Comments

@ianlancetaylor
Copy link
Contributor

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):

@ianlancetaylor ianlancetaylor added LanguageChange Suggested changes to the Go language v2 An incompatible library change NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 27, 2020
@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
@ianlancetaylor
Copy link
Contributor Author

There is another categorization of error handling proposals at https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/.

@ianlancetaylor ianlancetaylor added the error-handling Language & library change proposals that are about error handling. label Apr 28, 2021
@ianlancetaylor ianlancetaylor changed the title language: Go 2: error handling meta issue spec: error handling meta issue Aug 6, 2024
@ianlancetaylor ianlancetaylor removed LanguageChange Suggested changes to the Go language v2 An incompatible library change NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 6, 2024
@dr2chase dr2chase added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
error-handling Language & library change proposals that are about error handling. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. umbrella
Projects
None yet
Development

No branches or pull requests

2 participants