proposal: implicit if err != nil { return err }

[MarioGravel]

Having a global constant like _ to do a non-D.R.Y. job.

? can be a global constant of type error and when assign a non-nil value exit the function/method returning all zero values except the error which is the value assign to ?.

Here an example using ? as a global constant for the most, and by far, repeated code in Go.

func somethingReturningAnError() error {
    return errors.New("this is an error")
}

func somethingReturningAStringAndAnError() (*string, error) {
    str := "Awesome"
    return &str, errors.New("this is an error")
}

func somethingActual() error {
    err := somethingReturningAnError()
    if err != nil {
        return err
    }

    // Do something

    return nil
}

func somethingMoreDRY() error {
    ? = somethingReturningAnError()

    // Do something

    return nil
}

func somethingAlsoMoreDRY() (*string, error) {
    someText, ? := somethingReturningAStringAndAnError()

    // Do something

    return someText, nil
}

func main() {
    fmt.Println(somethingActual())

    fmt.Println(somethingMoreDRY())

    fmt.Println(somethingAlsoMoreDRY())

    // Output :
    // this is an error
    // this is an error
    // <nil> this is an error
}

[MarioGravel]

You still can continue to write if err != nil { ... } but ? indicate that you won't decide 'here' what to do with it and it will be relayed to a higher level (returned).

[mvdan]

Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

[phenpessoa]

I'm not sure I understand what ? would do in this case. But, isn't https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md a better proposal? (And somewhat similar to this)

[MarioGravel]

Well yes, it is similar., but the good thing about using a _, is that you know on the first look that the error isn't handled. Using another character, ? in my example, is also easy to figure out that the error will be returned and handled by the caller.

What I don't like about handle err { return err }, is that you don't see anymore where errors are returned in the code. it is pushed/hidden is the top of a function/method.

seeing i, _ := something("blabla") is like a "flag" that error are ignored.
seeing i, ? := something("blabla") is also very quick to know that the program will return the error, and zeroes values for other returned parameters, if there is an error

• it doesn't block the possibility for the handle err { return err } pattern.
• It can be added before version 2 of go without breaking code.
• it can remove the most "anti DRY" pattern of if err != nil { return err }

Personally, I like the way it is easy to see where errors can be returned(i, _ := something...), but it can be as clear by using a ? as it is by using _

[MarioGravel]

Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

@mvdan Got it, should I edit the existing one or close it and open a new one ?

[ianlancetaylor]

I think this is pretty much a dup of #25273, #32884, #33150. See also the meta-issue #40432.

[seankhliao]

Duplicate of #42214

[MarioGravel]

Duplicate of #42214

@seankhliao Sorry but I don't agree. My proposition is way less invasive. #42214 is proposing built-in function. I won't vote for this complexity. I'm proposing a global constant like _ with a different role. As soon as an error is assigned to ?, the function return with arguments' zero values and the error that was set to ?.

It is more rigid and have the only purpose to replace the if err != nil { return err }.
If you want to do something else with the error, continue to do it explicitly ! That's my point.

I'm currently writing some generic utility function and I'm constantly using this if err != nil { return err } pattern because the errors are handled by the caller or the caller's caller. There is 8 lines of statements that are function calls and they are all folowed by if err != nil { return nil }.