spec: error handling meta issue

[ianlancetaylor]

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 proposal: spec: the #id/catch error model, a rethink of check/handle #27519 and proposal: spec: named check-handle pairs for error handling #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: Proposal: spec: Bang! notation for error handling boilerplate #21155, Proposal: add token to syntax to reduce error boilerplate #25273, Proposal: Go 2: error handling by assignment, with named handlers #32500, Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884, proposal: Go 2: Use ?<variable> simplify handling of multiple-return-values #33074, proposal: Go 2: use symbol or function call in assignment for error handling #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: proposal: Go 2: error handling with functions and an error return? #27567, [Feature-Request/Proposal] Conditional Operator (error-handling) #28329, proposal: Go 2: on err or catch statement for error handling #32611, proposal: "?" as "!= nil" #32845, proposal: Go 2: onErr simple macro for common case error handling. A #32437 counter-proposal. #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]

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