Hi G., It takes guts to make a proposal in the Go community. Kudos for doing so.
However, the issue with this proposal for me is the issue I have with almost(?) every other proposal to handle errors in Go differently from what Go currently allows. They all make the assumption that as soon as an error occurs the *only thing* I would want to do is an immediate return, which I *almost never* do. Instead I almost always annotate errors with context to help when debugging logs, and often do some analysis to potentially resolve the error — such as a retry, or ignoring when not relevant — and the current structure of Go error handling, while I am sure it could be improved somehow, currently works extremely well for this. Also, I don't really like the idea of having to create a different function located a distance away in terms of code location from where the error occurs in order to be able to handle an error. I much better how Go optimizes my ability to address an error exactly at the point in which I recognize that an error occurred. As an aside, I would rather see Go make it easier to annotate errors with context in a way that does not require so much duplication of effort throughout the code than make it easier to just return early. So from a concerned-for-my-own-interests perspective if something that makes it easier to do an immediate return on `err!=nil` were added to Go and it were to be used ubiquitously it would make it much harder to me to stick with Go moving forward. #fwiw -Mike On Wednesday, November 9, 2022 at 4:42:55 PM UTC-5 paurea wrote: > On Wed, Nov 9, 2022, 20:47 Ian Lance Taylor <ia...@golang.org> wrote: > >> On Wed, Nov 9, 2022 at 10:40 AM Gorka Guardiola <pau...@gmail.com> wrote: >> >> Seems related to https://go.dev/issue/54361, although due to inject it >> is not the same. >> > > I hadn't seen that proposal. > >> > It is similar in the sense that it is a more powerful return, but this is > much more limited and restricted (1 call level explicitly annotated in the > function call vs. returning N levels to a label/function name). In that > sense it is a subset of what can be done with that change but more > structured. I feel it could be easier to reason about. > > The changes to the language, runtime, compiler... are also quite more > limited. The bad part is the need for two new reserved words. > > G. > > > -- 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/de56e687-9db7-476c-b042-eade94d4f00fn%40googlegroups.com.
