Or you know, just panic ... errors as value are a convention, not a language construct.
panic/defer ARE a language construct. I personally give the choice in my API, Must prefixed methods that panic or regular methods that return an error. The obvious advantage of panics is that the developer actually gets a stack trace for free, not need for 50 different packages that wrap errors just to get a stack trace. Le mardi 5 septembre 2017 11:17:13 UTC+2, Dorival Pedroso a écrit : > > 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> >> 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. >> > 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.
