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 <notificati...@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 > <https://blog.golang.org/go2-next-steps>. > > 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 > <https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md>,” > 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 > <https://golang.org/wiki/Go2ErrorHandlingFeedback>. > > 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 > <https://twitter.com/_rsc/status/1146129906323132416>. 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 > <https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAFSKXOFHX4J2LPP7BBLY23P7ZISDA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2CQYTY#issuecomment-512035919>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAFSKXMLF4PXSRYWBBELNX3P7ZISDANCNFSM4HTGCZ7Q>. > -- 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/B10CF79C-E5DE-44C2-B96C-998DDF4E9BC1%40bitblocks.com. For more options, visit https://groups.google.com/d/optout.
