Until Go has typed errors and a throws clause (I.e exceptions) it’s pointless.
You need to be able to be certain errors are handled or passed up at compile
time. The throws clause facilitates this. It allows refactoring without
breakage.
Until then just live with the boilerplate and keep your apps simple - not that
isn’t a good choice anyway.
Sent from my iPhone
> On Sep 14, 2018, at 6:38 AM, Liam <networkimp...@gmail.com> wrote:
>
> There are thirty-something counter-proposals on the feedback wiki! 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 page my thoughts on how
>> to improve upon the draft design for error handling:
>>
>
> --
> 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.
--
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.
