Go 2 error handling will bring a new errors idiom to the language
Go 2 is still a work in process. However, right now is the best time to chime in and make your opinion known. The latest item on the docket: error handling. Should the errors idiom in Go change? Here are some options up for discussion.
Go 2 is something of a far off goal for the Go community. However, on the heels of a successful Go 1.11 release (with modules!), it’s important to see where the language plans on going.
It’s been over a year since GopherCon 2017 and the last official update about road maps and milestones. We’re off the beaten path! The only markers we have left are a somewhat infrequently updated page on GitHub for the current status Go 2.
The latest draft under consideration is error handling. The official Go 2 Error Handling Overview is purposefully vague, with just four goals:
- Small-footprint error checks
- Developer-friendly error handlers
- Explicit checks & handlers
- Compatibility with existing code
This is meant to allow for community input and boy, does the community have ideas. Right now, there are almost 40 counter-proposals for error handling on the feedback wiki. While few of these comments explicitly lay out their reasons, the comments themselves suggest that the draft design needs more requirements and support.
Obviously, consensus is needed before the Go team designs the next draft. So, let’s take a look and see if we can find some common threads.
Taken from Liam Breck’s pithy list, here are a few pertinent changes that Go might go with. Obviously, we’re reporting on this list and not endorsing these changes; we just want to make sure all Go developers have a say. If you think we’ve forgotten something important, put it in the comments below or make your voice heard on the Go 2 wiki!
Here’s an overview of his plan:
- Allow Go1 error idiom to continue working
- Concise, reusable error “handlers” within a function and/or package. This includes things like uniquely identifiable handlers, letting the handler body contain any code that’s valid in the enclosing function, letting the handler parameter be of any type, and permitting handlers for deferred function calls.
- A concise, clear way to select a handler by name, either letting assignment or function call to invoke a handler.
- Let the name of an unreachable handler be reused.
- Let the function returning error and a value serve as an expression.
- Invoke handlers on Boolean false parameters.
- Let handling of an error skip over any statements between the statement triggering the handler and the handler body.
- Let handler continue the function.
- Let handler invoke another handler explicitly.
- Let handler perform context accretion.
- Permit package-level handlers, essentially a custom “predefined handler”.
- Provide predefined handlers.
- Calls to functions returning type
errorshall invoke a handler for the error value, or assign it to a variable
- Define keywords for
opabove. Consider any, or only C-family, or only Go1 keywords.
Again, these are only some of the ideas for changing the Go 2 error handling idiom. If you have any ideas, feel free to add them to the Go2 wiki page!
got to go 2