Re: [go-nuts] rin: return if nil syntactic sugar
> 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.
Re: [go-nuts] rin: return if nil syntactic sugar
Dear,
On Mon, Aug 31, 2020, 4:16 AM Zakaria bin Haris wrote:
> Hi, gophers!
>
> 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()
>
I love the consistency and the one way of doing things. It's indeed boring
to write 'if err ! nil', but I don't like the try catch either. Being
explicit is actually nice and errors as part of return values is more easy
to reason about.
I would rather pollute my code with if err than having two ways for return.
> 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
> }
>
> --
> 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/955d78f2-67cb-4940-845c-034fb45e816an%40googlegroups.com
>
> .
>
--
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/CAHrL7wHOD-eB%3D7A5C%3DtWW-wAPemBhXB09xQdocUwb87N1uveLQ%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
I read the try proposal and they're quite different from my simple
suggestion which is just a statement.
Pada tanggal Sen, 31 Agt 2020 14.02, Axel Wagner <
axel.wagner...@googlemail.com> menulis:
> Oh, sorry: I mixed the history up.
> AIUI this is the same as the try proposal with a different keyword and
> *that* got rejected for the "magical" control flow.
>
> On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner
> wrote:
>
>> On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
>>
>>> If the objections on the too magical handle part, why not cut that part
>>> and retain the check part?
>>>
>>
>> The objection was mainly on the too magical check part, AIUI.
>>
>>
>>>
>>> Most of the time the we just forward the error on to the next level
>>> anyway. Handling error is rarely done and should be explicit.
>>>
>>> I got better keyword for this: reterr
>>> A portmanteau of return error.
>>>
>>> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor
>>> menulis:
>>>
On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris
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.
Ian
>>> --
>>> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
>>>
>>> .
>>>
>>
--
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/CAET7US%3DCHcCL%2BioBMEt5TVzx66HCEfX5kvuLa_wWwiKq6Y_KMA%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
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/d7a23054-25d5-5cb3-2fd1-33a310bf4917%40gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
On Mon, Aug 31, 2020 at 3:31 PM Zakaria wrote: > If the objections on the too magical handle part, why not cut that part > and retain the check part? > > Most of the time the we just forward the error on to the next level > anyway. Handling error is rarely done and should be explicit. > It's important to note that Go has been around for >10 yrs and for the whole of that time people have proposed this same concept just with varying syntax. The concept has been debated on this list for more than a decade. The core developers are well aware of this possibility and its implications. -- 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/CAAuPoqc8rgz3gmfke4mnvjNPcj%3Dr_DjfUK1GEeyVxcQXSESVJA%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
On Monday, 31 August 2020 06:32:09 UTC+1, Zakaria wrote: > > If the objections on the too magical handle part, why not cut that part > and retain the check part? > > Most of the time the we just forward the error on to the next level anyway. > Often, good error handling requires replacing the error or wrapping it with context, rather than just passing the raw error upstream. Having a blessed way of saying "just return the raw error" will discourage good error handling practice. -- 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/176ad5db-362b-499a-856e-ce83bb47a00eo%40googlegroups.com.
Re: [go-nuts] rin: return if nil syntactic sugar
Oh, sorry: I mixed the history up.
AIUI this is the same as the try proposal with a different keyword and
*that* got rejected for the "magical" control flow.
On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner
wrote:
> On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
>
>> If the objections on the too magical handle part, why not cut that part
>> and retain the check part?
>>
>
> The objection was mainly on the too magical check part, AIUI.
>
>
>>
>> Most of the time the we just forward the error on to the next level
>> anyway. Handling error is rarely done and should be explicit.
>>
>> I got better keyword for this: reterr
>> A portmanteau of return error.
>>
>> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor
>> menulis:
>>
>>> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris
>>> 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.
>>>
>>> Ian
>>>
>> --
>> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
>>
>> .
>>
>
--
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/CAEkBMfGJR5GBNzaVRPp3nXAO9-AhfV%2BGV-Xx8d40GmGONzTgnQ%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
> If the objections on the too magical handle part, why not cut that part
> and retain the check part?
>
The objection was mainly on the too magical check part, AIUI.
>
> Most of the time the we just forward the error on to the next level
> anyway. Handling error is rarely done and should be explicit.
>
> I got better keyword for this: reterr
> A portmanteau of return error.
>
> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor
> menulis:
>
>> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris
>> 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.
>>
>> Ian
>>
> --
> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
>
> .
>
--
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/CAEkBMfEOAoXQmQPebRFYS7NpGXyyLzeZFoQSA%3DyC86zCbbz_gw%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
If the objections on the too magical handle part, why not cut that part and
retain the check part?
Most of the time the we just forward the error on to the next level anyway.
Handling error is rarely done and should be explicit.
I got better keyword for this: reterr
A portmanteau of return error.
Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor
menulis:
> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris
> 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.
>
> Ian
>
--
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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com.
Re: [go-nuts] rin: return if nil syntactic sugar
On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris 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.
Ian
--
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/CAOyqgcU5C4F-m_YPsPtxuPmt5TQrJnXN2QK4dGBONkYD1iKyww%40mail.gmail.com.
[go-nuts] rin: return if nil syntactic sugar
Hi, gophers!
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
}
--
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/955d78f2-67cb-4940-845c-034fb45e816an%40googlegroups.com.
