ianlancetaylor opened this issue
Jul 27, 2020
· 1 comment
Labels
error-handlingLanguage & library change proposals that are about error handling.Go2A change that can only be done in Go 2LanguageChangeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.umbrella
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):
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.
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
error-handlingLanguage & library change proposals that are about error handling.Go2A change that can only be done in Go 2LanguageChangeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.umbrella
1 participant
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.
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:
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):
check
/handle
proposal.handle
anddefer
.try
proposal.try
could cause the function to return. Go currently has no flow control constructs at the expression level, other thanpanic
which does more than just return from a function.!
or?
, that insert an error check in a function call or assignment.!
or other character leads to a change in flow control.if err != nil
, to reduce boilerplate.The text was updated successfully, but these errors were encountered: