And I will tell you that after working with error returns and exceptions, exceptions are superior - but much depends on the complexity of the system. For small system level tools that are pieced together via pipes, C error handling is fine - because the process serves as the exception handling point. For complex server long-lived processes, exception handling makes it much easier to design and deliver secure fault tolerant systems. Resilient Unix relies on the ability to start new processes to handle requests, track DoS attacks, faulty clients, etc. Process termination is a part of this. The Go runtime does not fit this model, so it needs to replicate it.
People write bad exception code - people write bad error return code. It’s easier to write and maintain good exception code. To this day, very few major systems are written in Go - at some point we have to ask honestly why - I think Go’s error handling is an important factor here. Go can probably get there without exceptions, but it entails standardized error declarations, wrapping, inspection, logging, etc. I think the Go2 error handling proposals attempt this. > On Feb 15, 2021, at 11:25 AM, Volker Dobler <dr.volker.dob...@gmail.com> > wrote: > > 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 > > <applewebdata://C7EB3610-725D-4CF7-B2B8-F20297ED1BAA>> wrote: > > > > Dnia 2021-02-13, o godz. 17:44:47 > > Michael MacInnis <michael.p...@gmail.com > > <applewebdata://C7EB3610-725D-4CF7-B2B8-F20297ED1BAA>> 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 > > <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 > > <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 > > <applewebdata://C7EB3610-725D-4CF7-B2B8-F20297ED1BAA>. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint > > > > <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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/36F15F71-CD50-4A86-8184-6F8023DB52D0%40ix.netcom.com.
