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.

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: Go 2: error handling: set error as return value by default from function #39972

Closed
Averianov opened this issue Jul 1, 2020 · 3 comments
Closed

proposal: Go 2: error handling: set error as return value by default from function #39972

Averianov opened this issue Jul 1, 2020 · 3 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Proposal

Comments

@Averianov
Copy link

Averianov commented Jul 1, 2020 •
edited

Set Error as return value by default from function

Hi all.
I proposal all functions can be return error by default. In the place where error handling is required, then call the corresponding function (handling() or ifError() or checkError() or etc.), here let it be someNameFunctionErrorHandling().
Do not beat strongly for a long name, it is for educate ;)

This simplifies error handling, do cleaner code and allows you to remember to pass the error up the stack.

See examples for understanding.

Overview

func anyFunc() error {var err error; return err} == func anyFunc() {}

so then

main()
|
˅
func() // if need error processing - "Any Error"
| ^
˅ |
func() // default forwarding error
| ^
˅ |
func() // getting an error - "Any Error"

Examples

Example 1

Old

func doAny() (int, error) {
  if true{  // simulate getting an error
    return 0, Errors.New("Any Error")
  } 
  return 1, nil
}

main() {
  _, err := doAny()
  if err != nil {  // error processing
    fmt.Println(err)  // "Any Error"
  }
}

New (at first glance nothing has changed)

func doAny() int {
  if true{  // simulate getting an error
    return Errors.New("Any Error"), 0  // allways error is the first returned value
  }
  return 1
}

main() {
  i := doAny()
  someNameFunctionErrorHandling() {  // error processing
    fmt.Println(err)  // "Any Error"
  }
}

Example 2

Old

func doAny() (int, error) {
  if true{  // simulate getting an error
    return 0, Errors.New("First Error")
  } 
  return 1, nil
}

main() {
defer func() {
  if err != nil {  // last error processing
    fmt.Println(err)  // "Second Error"
  }
}()
  _, err := doAny()
  if err != nil {  // current error processing from doAny()
    fmt.Println(err)  // "First Error"
    err = Errors.New("Second Error")
  }
}

New (we are able to immediately process the first error encountered)

func doAny() int {
  if true{  // simulate getting an error
    return Errors.New("First Error"), 0
  }
  return 1
}

main() {
  someNameFunctionErrorHandling() {  // first error processing
    fmt.Println(err)  // "First Error"
  }

  defer someNameFunctionErrorHandling() {  // last error processing
    fmt.Println(err)  // "Second Error"
  }
  i := doAny()
  someNameFunctionErrorHandling() {  // current error processing from doAny()
    fmt.Println(err)  //  "First Error"
  }
  err = Errors.New("Second Error")
}

Example 3

Old

func doAny() (int, error) {
  if true{  // simulate getting an error
    return 0, Errors.New("Any Error")
  } 
  return 1, nil
}

func doNext() error {
  ...
  _, err := doAny()
  if err != nil {
    return err
  }
  return nil
}

main() {
  err := doNext()
  if err != nil {  // error processing
    fmt.Println(err)  // "Any Error"
  }
}

New (we can forget to forward the error, but not here)

func doAny() int {
  if true{  // simulate getting an error
    return Errors.New("Any Error"), 0
  }
  return 1
}

func doNext() {
  ...
  doAny()
}  // just forwarding last error

main() {
  _ = doNext()

  someNameFunctionErrorHandling() {  // error processing
    fmt.Println(err)  // "Any Error"
    err = nil  // and can forwarding nil as error
  }
}

Thank you.
@gopherbot gopherbot added this to the Proposal milestone Jul 1, 2020
@ianlancetaylor ianlancetaylor changed the title Proposal: Go 2: error handling: set error as return value by default from function proposal: Go 2: error handling: set error as return value by default from function Jul 1, 2020
@ianlancetaylor ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Jul 1, 2020
@ianlancetaylor
Copy link
Contributor

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

@gopherbot gopherbot added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jul 1, 2020
@ianlancetaylor ianlancetaylor added the error-handling Language & library change proposals that are about error handling. label Jul 1, 2020
@davecheney
Copy link
Contributor

No thank you, this is too close to the way exceptions work in c++. Under your proposal, as the reader, I cannot tell if the function returns (or throws) an error.

@Averianov
Copy link
Author

Averianov commented Jul 2, 2020 •
edited

@gopherbot please remove label WaitingForInfo
Proposal is moved to https://groups.google.com/forum/#!forum/golang-nuts
Please close issue.

No thank you, this is too close to the way exceptions work in c++. Under your proposal, as the reader, I cannot tell if the function returns (or throws) an error.

What's the difference? The developer decides where to catch errors. But he does not need to worry about how to forward this error further. Сode becomes cleaner and more readable.

@golang golang locked and limited conversation to collaborators Jul 2, 2021
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 WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
4 participants
@davecheney @Averianov @ianlancetaylor @gopherbot