Go2ErrorHandlingFeedback

Go 2 Error Handling Feedback

This page is meant to collect and organize feedback about the Go 2 error handling draft design.

Please post feedback on your blog, Medium, GitHub Gists, mailing lists, Google Docs, etc. And then please link it here.

Please help categorize the rest of the uncategorized proposals at the bottom.

In support

This includes supporting the existing chaining/stacking of handlers without changes.

• Jeffrey Koehler, “In support of Handle Chaining; On Check”, August 2018

• Adam Bouhenguel "In support of more declarative error handling", August 2018

• Daniel Theophanes, "Go 2 Design: Error Handling Net Win", August 2018

Example code

Code changed to use the existing proposal.

• Mateusz Czapliński, "Converting a fragment of real code with error handling to Go 2 'design draft'", August 2018

Against

Critiques without counter-proposals

• Liam Breck, “Golang, How dare you handle my checks!”, September 2018

• Nate Finch, "Handle and Check, Let's Not", September 2018

• Shannon Wynter "Error Handling as it can already be done", August 2018

Counter-proposals

Error handling with normal functions

• Viktor Kojouharov, "Reducing the special casing around the new error design draft", September 2018

• Scott Pakin, "Go 2 error handling based on non-local returns", September 2018

• Aleksei Pavliukov, “Use a function as a handle parameter”, September 2018

• Greg Weber "Error handling with functions and an error return?", September 2018. Originally linked gist.

• Gigi Sayfan, “Go 2 error handling feedback + alternative solution", September 2018

• Ruan Kunliang, "Simple Error Handling for Go 2", August 2018

Labeled error handlers

• John Forstmeier, "Labeled error handling", September 2018

• Mikaël Cluseau, "Multiple handlers, unambiguous on which return value is used", September 2018

• Liam Breck, “The #id/catch Error Model”, September 2018

Inlining

• Vlad Didenko, “Error Handling with grab | name()”, November 2017

• Gooid, “Inline style error handle(simple unambiguous)”, August 2018

Just remove chaining/stacking

• Alessandro Arzilli, “Against check as an operator and handler chains”, August 2018

• Simon Howard, “Go 2 errors response: One Handler Per Function”, August 2018

• Andrew Phillips, “Improving Go Error Handling”, October 2017

• Eli Bendersky, "Thoughts on the Go 2 Error Handling proposal", September 2018

Use defer

• Victoria Raymond, “Force 'check' to return error instead of allowing customized logic”, August 2018

• Night-walker and daokoder, "Extend and repurpose defer instead of introducing new syntax", June 2014

try/catch/finally syntax

• Jan Semmelink, “if-else-undo-done”, August 2018

Other

• Fedir RYKHTIK, "Go 2 error handling with exclamation mark", September 2018

• jimmyfrasche, "Don't special case error or nil", September 2018

• Einthusan Vigneswaran, “Error Aware Keywords - return, defer, if, != and forcing the error object to be the last argument”, September 2018

• Jozef Slezak, "Use semicolons instead of new keywords: check+handle", September 2018

• Loki Verloren, “Go 2 error handling feedback and my thoughts on how to improve programmer's efficiency and experience”, September 2018

Uncategorized

Please help categorize the rest of the proposals here.

• Matt Dee "Error Handling Should Support Custom Error Types", August 2018

• DeedleFake, "Feedback for Go 2 Design Drafts", August 2018

• ZhiFeng Hu, "[Go2ErrorHandling] Go should support Exception handler", August 2018

• Paul Borman, “Arguments against the Go 2 error handling proposal", August 2018

• Savino Pio Liguori, "Feedback for Go2 error handling design", August 2018

• Blake Mizerany, “How best to account for partial writes when using check/handle?”, August 2018

• Garrus, "Another style of syntactic sugar on error handling", August 2018

• Marlon Che, "How about separating check and handle?", August 2018

• Patrick Kelly, "handling more than just errors in go", August 2018

• Yesuu Zhang, "Pass the check and handle parameters, custom handle", September 2018

Adding Your Feedback

Please format all entries as below.

• Your Name, “Title”, month year

To make it easier to see new feedback, please add your new proposal to the top of the section it is placed in.

Quick Comments

• DeedleFake: One of the issues with the syntax of check, as proposed, is that chaining method calls with error returns will look really, really bad. For example, check (check (check v.m1()).m2()).m3(). The common way around this in many languages is the use of ? as a postfix operator instead of prefix keyword, but this has other problems, including resulting in similar illegibility if there are nested function calls, such as in f1(f2(f3()?)?)?. So how's this for an alternate solution: When check is given a compound expression, such nested function calls or chained methods, it applies to all calls in the expression, not just the one it was specifically attached to. The previous two examples then become check v.m1().m2().m3() and check f1(f2(f3())), respectively. All other aspects of check remain the same, meaning that you could still use something like v, err := f1(check f2()) and whatnot.
  • DeedleFake: One potential awkwardness with this is the case of multiple returns being intended for use directly, such as with func f1(int, error); func f2() (int, error); check f1(f2()). It may be possible, however, for the application of check to be conditional on the usage of the types of each call, so it simply wouldn't affect the inner call to f2() in this case, the same as it not affecting a call to a function with no error return value. It would also be possible to get around this by manually calling f2() on a previous line, assigning the returns to values, and then passing those to f1().