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.

Reply via email to