Go 2 error handling requirements
927 views
Skip to first unread message
Liam
Sep 17, 2018, 11:42:29 AM9/17/18
to golang-dev
[I would like to post this on the issue tracker, tho it's not a proposal or bug report. Is that OK?]
Re the Go 2 draft design for error handling, there are thirty-something counter-proposals on the feedback wiki! I don't imagine that's the sort of feedback that the authors hoped for.
Apparently many folks see different requirement
sets for a new error-handling idiom, and the union of the sets is broad,
but the draft design targets a narrow set. Hence the dozens of
"better ideas" on the wiki, each conceived for different requirements. I think the Go team would benefit from a consensus on the
requirements before penning a next draft.
The draft design Overview gives just four rather vague "goals": small-footprint error checks, developer-friendly error handlers,
explicit checks & handlers, and compatibility with existing code. And previously @ianlancetaylor made this similar list:
Below is a comprehensive list of possible requirements. Please respond with any others that should be considered.
a) A less verbose error handling idiom than if err != nil { recurring_stmt }
a.1) Allow Go1 error idiom to continue working
b) Concise, reusable error "handlers" within a function and/or package
c) Let a statement select one of several handlers by name
>1/3rd of wiki posts suggest this
c.1) Ways that handlers could be uniquely identified, one of:
handler name, parameter name, label, ...
c.2) Classes of syntax to select a named handler.
A left-side and a right-side style could both be valid
op is a keyword or symbol; space between symbol and identifier is optional
v, handler op := f(p)
v, op handler := f(p)
v := op(f(p), handler)
v := op(handler, f(p))
v := f(p) op handler
v := handler op f(p)
v := f op handler(p) // n.b.
v, handler op := f(p)
v, op handler := f(p)
v := op(f(p), handler)
v := op(handler, f(p))
v := f(p) op handler
v := handler op f(p)
v := f op handler(p) // n.b.
d) Let function returning error nest in function calls, e.g.
x(f op handler (p)) // where func f(int)(int, error)
e) Let handler accept any return value, or only last one.
e.1) Let index of return value be specified (if not last one) when nested in function call, e.g.
x(f op handler . digit (p))
f) Let handler accept any type, or only type error
g) Let handler continue the function, e.g.
{ if err == io.EOF { break } } // stop enclosing loop, etc
h) Let handler invoke another handler explicitly, e.g.
{ if err != io.EOF { op quit = err } } // invoke "quit" handler
h.1) Let handler invoke another handler implicitly,
e.g. handlers with same name in related scopes.
i) Let handler perform context accretion, e.g.
{ return fmt.Errorf("blurb: %v", err) }
j) Placement of handler relative to statements that invoke it, either:
before, after
k) Permit package-level handler, accessible from any package function,
a variation on the "default handler" concept.
l) Provide a "default handler" to simply return input, named one of:
op _, op default, op return, ...
l.1) Behavior of default handler in main & goroutine functions which don't return, either:
panic, nothing
l.2) Provide a panicking default handler, e.g.
op panic = f(p) // or op ! etc
m) Consider new keywords, one of:
any new keywords
only established C/C++/Java keywords
no new keywords
PS: For those wondering why I've gone to all this trouble, it's because I had this reaction to the draft design :-)
Liam
Sep 24, 2018, 1:10:07 AM9/24/18
to golang-dev
I sought approval to post my requirements list to the issue tracker, but got no response, so I assume that's "No."
I've now expanded and clarified the Go 2 error handling requirements list, and committed it to a gist:
Feedback appreciated; feel free to comment there or respond here.
That gist is linked in a new Requirements section on the feedback wiki, which includes @ianlancetaylor's list of criteria:
On Monday, September 17, 2018 at 8:42:29 AM UTC-7, Liam wrote:
[I would like to post this on the issue tracker, tho it's not a proposal or bug report. Is that OK?]Re the Go 2 draft design for error handling, there are thirty-something counter-proposals on the feedback wiki! I don't imagine that's the sort of feedback that the authors hoped for.Apparently many folks see different requirement sets for a new error-handling idiom, and the union of the sets is broad, but the draft design targets a narrow set. Hence the dozens of "better ideas" on the wiki, each conceived for different requirements. I think the Go team would benefit from a consensus on the requirements before penning a next draft.The draft design Overview gives just four rather vague "goals": small-footprint error checks, developer-friendly error handlers, explicit checks & handlers, and compatibility with existing code. And previously @ianlancetaylor made this similar list:Below is a comprehensive list of possible requirements. Please respond with any others that should be considered.
. . .
Liam
Oct 8, 2018, 6:20:26 AM10/8/18
to golang-dev
I've further expanded and clarified Requirements to Consider for Go 2 Error Handling:
It has new items covering handlers in the defer stack, and a rule that functions returning type error either invoke a handler or assign the error to a named variable.
Feedback appreciated; feel free to comment there or respond here.
The gist is also linked in the Requirements section on the feedback wiki, which includes @ianlancetaylor's list of criteria:
Liam Breck
Nov 5, 2018, 2:29:52 PM11/5/18
to golang-dev
I've further revised Requirements to Consider for Go 2 Error Handling:
It has a new section (O) covering automated test of error handlers, expands (D) with an item to minimize boilerplate, and gives new examples for (G) & (H).
Feedback appreciated; feel free to comment there or respond here.
It's linked in the Requirements section on the feedback wiki
Liam Breck
Dec 14, 2018, 4:16:32 PM12/14/18
to golang-dev
I've done some gardening in the feedback wiki
There's a new section "Modest revisions" which pulls several posts out of the sections Uncategorized and Other possibilities.
I pulled posts from @jimmyfrasche, @warrenstephens, and @mattdee123 into section Requirements.
In section "try/catch/finally" I added the Rust RFC which covers the catch construct they're now implementing. Sadly, this catch is essentially a try, but they'd already consumed the try keyword for other purposes.
And there's a few new additions and clarifications in Requirements to Consider for Go 2 Error Handling:
Cheers!
Reply all
Reply to author
Forward
0 new messages