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:
>>
>> 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.
