Exactly: a good amount of "if err != nil" appears in my tests (334 out of 569). I'll try to re-think the other cases... (e.g. https://github.com/cpmech/gosl/blob/master/la/blas2.go)
No complaints here, by the way! Just enjoying this marvellous language! I'll read the blog post. Cheers. 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.