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,
> [email protected] 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
