Preparing defaults for multiple-values-returning functions

[Tong Sun]

I want to define a default set of values for the multiple-values-returning function, so when doing error checking along the way, I can return such default set when things go wrong.

How can I do that? 

Is it possible to make the 17&18 line of the following working?

https://play.golang.org/p/OX6QwWXc2ch

thx

[Robert Engels]

I think the more idiomatic way would be

if err!=nil {

   goto return_defaults

}

This is pretty standard for multiple values. It also allows earlier checks to alter some of the defaults if they are declared as local variables.

--
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/b74868fc-65a0-4b04-a898-411139b3b9f8%40googlegroups.com.

[Burak Serdar]

https://play.golang.org/p/_U4CvzTBxkX

[Tong Sun]

On Monday, July 22, 2019 at 2:59:33 PM UTC-4, Burak Serdar wrote:

On Mon, Jul 22, 2019 at 12:51 PM Tong Sun <sunto...@gmail.com> wrote:
>
> I want to define a default set of values for the multiple-values-returning function, so when doing error checking along the way, I can return such default set when things go wrong.
>
> How can I do that?
> Is it possible to make the 17&18 line of the following working?
> https://play.golang.org/p/OX6QwWXc2ch

https://play.golang.org/p/_U4CvzTBxkX

Ah, bingo! This is much better than the "goto return_defaults" solution in my view. THX a lot!

 

>
> thx
>
> --
> 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 golan...@googlegroups.com.

[Robert Engels]

Depends on the length of the function, and number of branches/tests/nested levels IMO.

Having clearly labelled exit points at the end has been a best practice for a long time AFAIK. This is especially true with multiple return values, and if different exit points return values that are dependent on computation prior. It also the return values to be more easily self-documented IMO.

-----Original Message-----
From: Tong Sun

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/461b3039-182d-4796-9491-3da131871363%40googlegroups.com.

[Thomas Bruyelle]

I prefer to define a local func that returns the default values.

https://play.golang.org/p/UOPdouwoy0v

(Moreover you should avoid using `else` behind `return`)

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/461b3039-182d-4796-9491-3da131871363%40googlegroups.com.

[jake...@gmail.com]

(Previous post deleted to to premature "Post")

My 2 cents. I'm a seasoned Go programmer with years of professional Go experience, and decades of coding work.

Personally, I would avoid goto if possible. It may "have been a best practice for a long time" in C/C++ and other languages. But in Go, I find there are usually better ways to write such code. The are situations where a goto for exit cleanup is the clearest solution, but I recently worked on a 50k line group project where we only did it once.

Another, a personal preference - I dislike bare returns in most situations. I know I am not alone in this opinion. Specifying the return values explicitly is just clearer, avoids a class of bugs, and can make reading the code quicker and easier.

func ret2(b bool) (int, int) {
     if b {
        return 1, 2
    }
    return 2, 3
}

Or

func ret2(b bool) (x, y int) {
    x = 1
    y = 2
    if b {
        return x, y
    }
    return 2, 3
}

Of course, the second one only makes sense if there are multiple returns that use the "defaults".

When writing Go code, I think it is always good practice to consider readability. Locality is a big part of that. With a bare return there is fundamental information "missing" at the point of the return.

[Robert Engels]

That’s my feeling. Bare returns are not good. The easiest and most readable solution to the OPs problem and not using bare returns is labeled exits. Local functions quickly become unwieldy when multiple are required IMO. 

On Jul 23, 2019, at 11:03 AM, jake...@gmail.com wrote:

On Monday, July 22, 2019 at 2:51:43 PM UTC-4, Tong Sun wrote:

My 2 cents. I'm a seasoned Go programmer with years of professional Go experience, and decades of coding work.

Personally, I would avoid goto if possible. It may "have been a best practice for a long time" in C/C++ and other languages. But in Go there are usually better ways to write code. The are situations where a goto for exit cleanup is the clearest solution, but I recently worked on a 50k line project where we only did it once.

Another, a personal preference - I dislike bare returns in most situations. I know I am not alone in this opinion. Specifying the return values explicitly is just clearer, avoids a class of bugs, and can make reading the code quicker and easier.

func ret2(b bool) (int, int) {
     if b {
        return 1, 2
    }
    return 2, 3
}

Or

func ret2(b bool) (x, y int) {x=1
        y=2
    if b {
        return

    } else {
        x,y = 2, 3
        return
   

--
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/b1b11fcd-5796-49b0-9346-1a222c6a6e32%40googlegroups.com.