That proposal is materially different, due to using handler functions, rather than the already existing scoped labels, both in terms of cognitive load - where is the function called - what does the stack look like?What about panics?, and in terms of lines of code (functions are far more verbose). The goto label is far simpler IMO.
It also omits the __error variable which is the key to making the code simple and easy to reason about. > On Jul 9, 2019, at 9:54 PM, Liam <networkimp...@gmail.com> wrote: > > See https://github.com/golang/go/issues/32500 > >> On Tuesday, July 9, 2019 at 10:25:36 AM UTC-7, Robert Engels wrote: >> >> There is probably a similar proposal out-there, but if there is it hasn't >> surfaced, so I thought I would throw this out there. >> >> It only requires 2 simple changes and is completely backwards compatible. >> >> Currently, idiomatic Go error handling code looks like this: >> >> v,err := somefunc() >> if err!=nil { >> // do something, in many cases, just return err >> } >> >> but a substantial amount of Go code has handling code like this: >> >> v,err := somefunc() >> if err!=nil { >> goto some_error_handler >> } >> >> especially when there is common wrapping of errors, or retries. >> >> With the proposal https://github.com/golang/go/issues/27165 accepted (at >> least Rob likes it), the error handling can be simplified by >> >> v,:some_error_handler := somefunc() >> >> which is essentially an if with goto macro. >> >> The only other addition is a compiler provided 'function scoped' variable >> __error which is the last error returned by the last called function. This >> allows for trivial writing of the error handler block, as an example: >> >> some_error_handler: >> return errors.New("function failed",__error) >> >> or even >> >> some_error_handler: >> retry++ >> if !__error.Permanent() && retry < N { >> goto try_again >> } >> return errors.New("function failed",__error) >> >> And since goto/labels in Go are already scoped, it allows inner handlers, as >> in: >> >> for _,x := range blah { >> v,:localerr := somefunc() >> defer v.Close() >> x,:localerr := anotherfunc(x) >> continue >> localerr: >> return errors.New("unable to process item ...",__error) >> } >> >> I think this coupled with the xerrors enhancements would dramatically >> improve Go error handling. It is still very explicit, no hidden flow, plays >> nicely with defer, all returns are explicit, easy to read - no magic. >> >> And if the function has minimal (or no) error handling required, it is >> written just as before. >> >> A simple enhancement might be a pseudo handler label :return that always >> returns the 0 values for all results parameters, and __error as the err >> parameter. In many ways this would be similar to the current 'try' proposal. >> >> The limitation of this solution is that nested calls are not possible as >> with 'try', but they would instead be done on multiple lines, as in: >> >> v,:return = somefunc() >> x,:return = another(v) >> y,:return = yetanother(x) >> >> which I think is easier to reason about. >> >> Anyway, just a thought. >> >> >> >> >> >> > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/416e6e2f-1bcf-4199-bc3d-119a4b8978fc%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/87247EE6-B5BE-4C78-921E-1294F7669614%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
