rin: return if nil syntactic sugar

[Zakaria bin Haris]

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

  }

[Zakaria bin Haris]

Sorry, I mean return if not nil, so it should be rinn or please find some better keyword for this :^).

[Zakaria bin Haris]

For completeness if the function is something like:

  func x() (data *Data, err error) {

  }

then rinn should be smart enough to assign error to err variable and just do return instead return err

[Zakaria bin Haris]

Cause the objection for previous error handling is code coverage, the solution is for code coverage tools to desugarize rinn syntax.

The objective to minimize error handling "noise" from human eyes.

[Ian Lance Taylor]

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

[Zakaria]

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.

[Axel Wagner]

On Mon, Aug 31, 2020 at 7:32 AM Zakaria <z4k...@gmail.com> 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.

 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com.

[Axel Wagner]

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.

[Brian Candler]

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.

[Jesse McNelis]

On Mon, Aug 31, 2020 at 3:31 PM Zakaria <z4k...@gmail.com> 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.

[Kevin Chadwick]

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.

[Zakaria]

I read the try proposal and they're quite different from my simple suggestion which is just a statement.

[Mohamed Yousif]

Dear,

On Mon, Aug 31, 2020, 4:16 AM Zakaria bin Haris <z4k...@gmail.com> 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...@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.

[Denis Cheremisov]

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