The solution to Close returning an error, is to defer Close() and then have a second Close() with error checking in the happy path.
I just wish the io.Closer contract would require, that this has to be safe (= not panic). Luckily it is, for the vast majority of Closers at least. On Fri, Sep 8, 2017 at 6:01 PM, <ekoc...@gmail.com> wrote: > 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> 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. > -- 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.
