There are *thirty-something* counter-proposals on the feedback wiki
<https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback>! It's a bit of
a train wreck :-p
What that means, I believe, is that many folks see different requirement
sets for a new error-handling idiom, so the union of the sets is broad, and
the Go team's draft design targets a narrow set. Hence the dozens of
"better ideas" on the wiki, each targeted to a different requirement set.
What we need isn't a better idea, it's a consensus on the requirements for
a broadly acceptable solution.
I see some points of consensus:
a less distracting error handling idiom than if err != nil {
recurring_procedure }
reusable error handlers within a function and/or package
a way to invoke one of several error handlers by name; over 1/3rd of wiki
posts suggest this
Other points to seek consensus:
Assuming a way to select one of several handlers when calling a
function...
In what ways can handlers be uniquely identified?
e.g. handler name, parameter name, label
What are the classes of syntax to select a handler? e.g.
v, handler := fn (p)
v := builtin(fn (p), handler)
v := fn (p) <operator> handler
v := handler <operator> fn (p)
v := fn <operator> handler (p)
Should functions returning an error be nestable in function calls?
func f(int)(int, error); x(f(p))
If so, which of the above classes of syntax to select a handler can
nest?
Should handlers work for return values other than the last one? e.g.
handler, v := f(p)
Should handlers accept any type, or just error?
Should a handler be able to continue the function, or only abort it?
Should a handler be able to invoke another handler by name?
Should handlers support context accretion in the error?
err = fmt.Errorf("blurb: %v", err)
If so, what are the options? e.g. implicit chain, explicit chain,
per-scope context accretor
Should a handler appear before or after the statements that may invoke it?
Should there be package-level handlers, accessible from any package
function?
Should there be a "magical" default handler?
What should a default handler do in main & goroutine functions which
don't return?
Should new keywords be considered?
In the event that anyone responds to the above questions instead of posting
yet another counter-proposal, I'll post a tally of responses for each point
:-)
Cheers!
On Thursday, September 13, 2018 at 12:29:03 PM UTC-7, Scott Pakin wrote:
>
> I recently added to the Go 2 Error Handling Feedback
> <https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback> page my
> thoughts on how to improve upon the draft design for error handling
> <https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md>
> :
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
