> > P.S. someone else proposed wrapper with error handling in defer. > IMO it is as bad as watch - spooky, at distance, clunky. >
That was me. My background is many years of C++ and it feels natural to me (RAII). I follow the pattern: there must be defer Close immediately after acquire action, so it is very obvious in code review if there's a resource leak or not and if it's panic safe or not. Unfortunately when a defer is used, another defer is often necessary. I read this blog post a while ago: https://joeshaw.org/dont-defer-close-on-writable-files/ He seems to agree with you ("Still, I find this pattern to be a little too magical."), but his other alternative examples do not seem very convincing... On Friday, September 8, 2017 at 11:03:44 AM UTC+2, ohir wrote: > > On Thu, 7 Sep 2017 17:03:06 -0700 (PDT) > Dorival Pedroso <ped...@cpmech.com <javascript:>> wrote: > > > > Wouldn't be great to have a "syntactical sugar" to make things (at least > a > > little bit) simpler in our beloved Go language? > > No. Proposed (*also by past me*) "watch" construct is bad for anyone > reading code, bad for code consistency and is unable to provide any real > value in spite of high expectations. I coined it as a freshmen to Go then > I gave it up after few tries to "implement" it with code generator just > after > "spooky action at distance is bad" turned out to be so true. > > > Simpler would certainly encourage people to handle errors properly > > "Watch" is NOT simpler. It bears "at distance" burden. It does not give > debugging person a way to know which call under watch went wrong. > The explicitness of if err!=nil { ... } is. > > > Of course, we don't need the "watch" command for these. In fact, we need > > nothing special in Go to properly handle these errors. > > Yes. And I have learned it weeks after my "I wanna watch" fool. > (The reason for "watch" was porting an ugly code to check validity of many > fields in complicated financial messages). > > Had I have "watch" at hand I would end blindly (albeit automated) > rewriting > try/catch spaghetti code for each MT. Fortunately I had no "watch" so I > got > to the table, then to the map (for maintenance reasons. See here map: > https://play.golang.org/p/3PDgjCgPMK . Every try/catch block rewritten in > Go became simple call of validate(&MT, "ABA","SC","RSN") shape). > > For SQL call chains you may use "For/Switch" pattern: > https://play.golang.org/p/0gWarQ8TL7 . > > For/Switch is clear and can cope with e.g. retries for a 5 lines more: > https://play.golang.org/p/CyhIJabzFn > > watch: > for i = 1; retry < 3; i++ { > if err != nil { > i-- > retry++ > continue > } > switch i { > case 1: > err = getData(i) > case 2: > err = getData(i) > case 3: > err = getData(i) > default: > break watch > } > } > if err != nil { > // handle common error > } > > All above patterns have single err handling place yet give back > information > where err was set -- something "watch" knows nothing about. > > P.S. someone else proposed wrapper with error handling in defer. > IMO it is as bad as watch - spooky, at distance, clunky. > > -- > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
