Re: [golang/go] Proposal: A built-in Go error check function, "try" (#32437)

[Bakul Shah]

And a big thank you to the Proposal Review Committee for shepherding this proposal & the ensuing discussion. "Open source community-wide discussion at its best" would be very hard to conduct without such a moderating influence. I learned quite a bit. Much appreciated.

Cheers,

Bakul

On Jul 16, 2019, at 4:11 PM, Robert Griesemer <notifi...@github.com> wrote:

Hi everyone,

Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.

Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.

As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.

More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.

As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.

(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)

On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.

Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.

Robert Griesemer, for the Proposal Review Committee.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.