I think there is strong consensus, that the current style of error handling is currently the best option. Nobody has been able to come up with something better (really better, not just more comfortable while ignoring hefty drawbacks).
It is true that a loud minority seems to miss exceptions to a point where they are unwilling to even try the language. How much their expertise counts if they never really worked with proper error handling in Go is debatable. Having worked with error returns and exceptions I can tell you that proper error handling with exceptions is much more painful than with errors. But of course: If your infrastructure, your business requirements and your acceptance criteria allow for making any problem a problem of someone else than exceptions are godsend. V. On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote: > I think ’strong census’ is not accurate - thus the discussions around > improving error handling in Go2. > > Many have commented here and elsewhere that the number one reason they > don’t use Go is due to lack of exception handling. > > > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki <oh...@fairbe.org> > wrote: > > > > Dnia 2021-02-13, o godz. 17:44:47 > > Michael MacInnis <michael.p...@gmail.com> napisał(a): > > > >> I've been playing around with reducing error handling boilerplate > > > > You're not alone. Hundreds of us went into such thinking in the first > weeks > > of reading/using Go - yet before we noticed how much more productive we > > are with Go's "boilerplate" than we were in languages where handling > errors > > (failures) was "a problem of others", including future-us as "others". > > > > Perceived consensus of the Go community is that "error handling > boilerplate" > > is a strong feature. I.e. in normal production software you MUST handle > failures > > and you should do it as close as possible to the source of said failure. > > > > Go helps with that. Even team's proposal was finally retracted: > > https://github.com/golang/go/issues/32437 Discussion there is lengthy, > but worth > > reading to sense why wider community considers "boilerplate" as asset. > > > > Error handling proposals umbrella: > https://github.com/golang/go/issues/40432 > > > >> Michael. > > > > Hope this helps, > > > > -- > > Wojciech S. Czarnecki > > << ^oo^ >> OHIR-RIPE > > > > -- > > 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint > . > > -- 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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com.