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 <[email protected]
> <javascript:>> wrote:
> > Fair enough. This would be perfect. Cheers
> >
> >
> > On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10,
> > [email protected] 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,
> >>> [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] <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 [email protected].
For more options, visit https://groups.google.com/d/optout.
