> I am using flutter and so Dart for the frontend right now, and I have
come to a
Error context has a little value in the end user apps, I noticed this too
at the example of just CLI utilities. It is totally different when it comes
to modern network systems, because there're far more places of errors
there. Imagine you have requested an item and this leads to fetching data
from several sources and you got an error at one. Imagine you did not
decorate it and got some basic network error. It will be nearly useless as
it is. Decorated one will be useful:
return errors.Wrap(err, "request something from service.method")
And you are asking engineers what is wrong with that service, or dig into
yourself. Problem solved.
Sure, it is artificial example, but the pricnicple is one: there are lots
of places where you can get at error in distributed systems. Context is
extremely useful.
понедельник, 31 августа 2020 г. в 12:06:16 UTC+3, m8il...@gmail.com:
> On 2020-08-31 03:34, Ian Lance Taylor wrote:
> >> Idk if this has been proposed or discussed before.
> >>
> >> Given the last error handling abbreviation proposal is rejected. How
> about some simple syntactic sugar like this:
> >>
> >> rin Something()
> >>
> >> Which is just a sugar for:
> >>
> >> if err := Something(); err != nil {
> >> return err
> >> }
> >>
> >> To make it worth the new keyword make it so that:
> >>
> >> rin v := Something()
> >>
> >> equals to:
> >>
> >> v, err := Something()
> >> if err != nil {
> >> return err
> >> }
> > This is similar to the check/handle design draft, without the handle.
> > You may want to take a look at https://golang.org/issue/40432.
> > Thanks.
>
> I am using flutter and so Dart for the frontend right now, and I have come
> to a
> conclusion that is related but perhaps beyond magical. It is my opinion
> that
> having additional syntax simply for syntactic sugar reasons offers little
> benefit but pointless cognitive load when reading code. I now remove
> syntactic
> sugar in Dart like => and ... in my codebases. As the full syntax does the
> same
> thing but offers greater functionality, I see negatives with negligible
> benefit
> in any case.
>
> Especially when there is the potential for code readers to switch from
> backend
> to frontend and not necessarily being masters in both languages.
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/70a1bb39-cb66-4447-86a4-11a67c576d75n%40googlegroups.com.
