Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
MarioGravel opened this issue Oct 20, 2022 · 8 comments
Closed

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

MarioGravel opened this issue Oct 20, 2022 · 8 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@MarioGravel
Copy link

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
}
@gopherbot gopherbot added this to the Proposal milestone Oct 20, 2022
@MarioGravel
Copy link
Author

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).

@MarioGravel MarioGravel changed the title proposal: affected/package: proposal: core langage Oct 20, 2022
@MarioGravel MarioGravel changed the title proposal: core langage proposal: implicit if err != nil { return err } Oct 20, 2022
@mvdan
Copy link
Member

mvdan commented Oct 20, 2022

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

@phenpessoa
Copy link

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
Copy link
Author

MarioGravel commented Oct 20, 2022 •
edited

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
Copy link
Author

MarioGravel commented Oct 20, 2022 •
edited

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 ianlancetaylor added LanguageChange v2 A language change or incompatible library change error-handling Language & library change proposals that are about error handling. labels Oct 20, 2022
@ianlancetaylor
Copy link
Contributor

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

@seankhliao
Copy link
Member

Duplicate of #42214

@seankhliao seankhliao marked this as a duplicate of #42214 Oct 20, 2022
@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Oct 20, 2022
@MarioGravel
Copy link
Author

MarioGravel commented Oct 21, 2022 •
edited

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 }.

@golightlyb golightlyb mentioned this issue Dec 10, 2022
Closed
@golang golang locked and limited conversation to collaborators Oct 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
6 participants
@ianlancetaylor @mvdan @phenpessoa @gopherbot @seankhliao @MarioGravel