Thanks again, Rob. The blog post (https://blog.golang.org/errors-are-values) does shed some light.
One of the ideas is to hold the *err* variable in a structure. I will definitively use this more often (I do have many structures and never thought of doing this!)---Thanks! The other idea is to create a wrapping structure (e.g. type errWriter struct {w io.Writer; err error}) just to keep hold of the *err* variable. In this case, I'd prefer to return *err* in my "pure function" (I also have many of those; e.g. for "mathematical computations"). In this case, I actually don't mind returning and checking the err variable as long as I don't need the wrapper. Now, this piece of code: ew := &errWriter{w: fd} ew.write(p0[a:b]) ew.write(p1[c:d]) ew.write(p2[e:f]) // and so on if ew.err != nil { return ew.err } could easily (?, I don't know) be replaced by: *watch* err != nil { return err } err = fd.write(p0[a:b]) err = fd.write(p1[c:d]) err = fd.write(p2[e:f]) // and so on and we wouldn't need the wrapping structure... (sorry for being so lazy ;-) By the way, maybe one day I'll attend a GoCon and will bring a laptop for sure... Cheers. Dorival On Tuesday, September 5, 2017 at 6:39:05 PM UTC+10, Rob 'Commander' Pike wrote: > > If you find that lines like if err != nil are a significant fraction > of non-test code, your code probably needs a better error handling > strategy, not a language change. I have done measurements in the past > and although people complain a lot about the presence of that > statement, it shows up much less often in practice than people claim, > and when it does appear a lot it's usually because the programmer is > not thinking enough about how errors should work. > > Please reread that blog post. > > -rob > > > On Tue, Sep 5, 2017 at 5:45 PM, Dorival Pedroso <ped...@cpmech.com > <javascript:>> wrote: > > Fair enough. This would be perfect. Cheers > > > > > > On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10, > > marti...@programmfabrik.de wrote: > >> > >> Dorival, > >> > >> I think we can celebrate already if we achieve anything with this > >> discussion. Let's not ask for too much, plus let's not make it too > >> complicated. > >> > >> I think your proposed "watch err", hides too much and does too little. > >> > >> You can simply write (the inline code editor is broken, BTW) > >> > >> func ... { > >> var err > >> watch err != nil { > >> // handle error > >> return > >> } > >> // do stuff > >> yo1, err := do_stuff1() > >> yo2, err := do_stuff2() > >> yo3, err := do_stuff3() > >> } > >> > >> > >> Martin > >> > >> > >> On Tuesday, September 5, 2017 at 9:32:50 AM UTC+2, Dorival Pedroso > wrote: > >>> > >>> Hi Martin; > >>> > >>> What about two commands "watch" and "watchif"? > >>> > >>> The first works as the "var" command and the second as the "if" > command. > >>> > >>> "watch" does: > >>> > >>> In a function with error as an output (anywhere): returns in case the > err > >>> declared with watch err (or watch myerror) becomes non-nil. watch err > would > >>> declare err" as var does. Most use cases would put watch err at the > >>> beginning of a function (although this is optional as it is with > defer) > >>> In a test function; aka TestSomething(something *testing.T), watch err > >>> error would declare err (or watch myerror error) and if an error > occurs, it > >>> would call something.FailNow() after (printing the error > message?---still > >>> need to think this part better) > >>> In the main function: watch err error would print the error message > (or > >>> maybe pipe to stderr) and os.Exist(1) > >>> watchif err != nil {HERE} would be more powerful because it would > allow > >>> us to do other things. But the mechanism is similar (as you proposed > >>> initially): if err becomes non-nil anywhere, the execution in HERE > would > >>> take place. > >>> > >>> Cheers! > >>> > >>> > >>> On Tuesday, September 5, 2017 at 4:55:59 PM UTC+10, > >>> marti...@programmfabrik.de wrote: > >>>> > >>>> Hi Dorival, > >>>> > >>>> thanks for supporting me with my idea. > >>>> > >>>> And yes, after writing my post yesterday I was thinking, "watchif" or > >>>> even simply "watch". > >>>> > >>>> And yes, today I am more in favor of simply "watch". > >>>> > >>>> And yes, we can constrain this to the context of one function (like > >>>> defer), I am ok with that. > >>>> > >>>> What you are describing how you work with errors and how you spent > hours > >>>> adding > >>>> > >>>> if err != nil > >>>> > >>>> that is exactly my point. > >>>> > >>>> On could nicely write this > >>>> > >>>> ... > >>>> watch err!=nil { > >>>> handle_sql_error(err) > >>>> } > >>>> ... > >>>> > >>>> Of course, watch could also be used to not watch out for errors but > any > >>>> other places where new values to get assigned to variables. > >>>> > >>>> Martin > >>>>>> > >>>>>> > > -- > > 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 <javascript:>. > > 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.