I wanted to express my thanks to Mickael McKinnus for his research. I am someone who is quite happy with the error handling in Go as it lets me implement whatever I like, I must say it is obviously flawed from the standpoint that the proper constructs are not part of the language but part of our training. The discreet patterns I use are:
- Handle errors that can be handled close to where they occur. - Report errors that cannot be handled because they were caused by the calling function passing a bad parameter. - Panic on errors that prevent a function that MustComplete from completing because they cannot be handled. - Try a MustComplete() with recover from the panic that reports to the User and or Developer the nature of the problem and how to resolve it manually or at least add it to issues. - Ensure that no matter what happens, you do not corrupt the HDD, lockup the hardware, CTD, or leave unexpected artefacts on the screen. There is no one best way of dealing with errors but there are patterns for dealing with errors, if you only learn one pattern then you will not be writing good code (if you only have a hammer, everything looks like a nail). Golang does not have error patterns that are clear and distinct for novice programmers and it does not inhibit advanced programmers from dealing with errors in whatever way they think appropriate. A useful abstraction would be to simplify the error handling by identification of the type of pattern desired and use the most concise and yet easily understood way of writing it. Go has tools in place to allow each user to create a preprocessor for error handling or any other purpose but it would be nice if we were all on the same page. On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com wrote: > 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.volke...@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> >> 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...@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/7a9dff68-16fe-4059-9eb2-2962c58ff6ddn%40googlegroups.com.
