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: > > 1. 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*) > 2. 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) > 3. In the main function: *watch err error* would print the error > message (or maybe pipe to stderr) and os.Exist(1) > 4. *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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.