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

proposal: Go 2: error handling with handle keyword and optional return of error type #54677

Closed
MikhailBatsin-code opened this issue Aug 25, 2022 · 5 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change
Milestone

Comments

@MikhailBatsin-code
Copy link

MikhailBatsin-code commented Aug 25, 2022

Would you consider yourself a novice, intermediate, or experienced Go programmer? - intermediate.
What other languages do you have experience with? - rust/haskell/c/ruby.
Would this change make Go easier or harder to learn, and why? - no effect.
Has this idea, or one like it, been proposed before? - can't say.
Who does this proposal help, and why? - possibly it will help everyone, because it will make whole error handling more convenient.
Is the goal of this change a performance improvement? - no
Does this affect error handling? - yes. Key differences: backward compatible, (kinda) looks like other parts of the go, no new types, function signatures the same.

What is the proposed change?

  • return of nil value for error will be optional.
  • new keyword handle, that will work with errors.
  • In language spec Errors section will be changed due to new way of error handling

Please also describe the change informally, as in a class teaching Go.

Basically, there will be easier way of error handling with new keyword handle, that checks if function returns error and if there is no handle body, it will just return error or exit function with default values for other return parameters. Additionally, returning nil value for error will be optional.

Is this changes backward compatible?

Yes, because nothing there will change function signatures, or anything else that can break backward compatibility.

Example

before

package main

import ...

func get(url string) (string, error) {
    resp, err := http.Get(url)
    if err != nil {
        return "", err
    }

    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }

    return string(body), nil
}

func main() {
     contents, err := get("http://example.com")
     if err != nil {
         fmt.Println(err)
         os.Exit(1)
     }
     fmt.Println(contents)
}

after

package main

import ...

func get(url string) (string, error) {
    // will return error if http.Get() returns error
    resp := handle http.Get(url)

    defer resp.Body.Close()

    body := handle io.ReadAll(resp.Body)
    return string(body)
}

func main() {
     // handle logic can be changed with this syntax
     // -> err syntax means that error will be put in variable with that name.
     // but "-> err" can look better i think 
     contents := handle get("http://example.com") -> err {
          fmt.Println(err)
          os.Exit(1)
     }
     fmt.Println(contents)
}

Affected tools

  • gopls
  • gofmt

Other pros

  • Better readability
  • Smaller functions
  • Clearer code
@gopherbot gopherbot added this to the Proposal milestone Aug 25, 2022
@seankhliao
Copy link
Member

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

@seankhliao seankhliao added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 25, 2022
@ianlancetaylor ianlancetaylor added LanguageChange v2 A language change or incompatible library change error-handling Language & library change proposals that are about error handling. labels Aug 25, 2022
@ianlancetaylor
Copy link
Contributor

It seems rather subtle to have flow control change based on a single character @. That is unlike anything else in Go.

@MikhailBatsin-code MikhailBatsin-code changed the title proposal: Go 2: error handling with handle keyword, operator @, optional return of error type proposal: Go 2: error handling with handle keyword and optional return of error type Aug 26, 2022
@MikhailBatsin-code
Copy link
Author

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

i filled this out

@seankhliao seankhliao removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 31, 2022
@ianlancetaylor
Copy link
Contributor

This is like other earlier rejected error proposals, such as #32437. See also #40432. This is a likely decline. Leaving open for four weeks for final comments.

@ianlancetaylor
Copy link
Contributor

No further comments.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2022
@golang golang locked and limited conversation to collaborators Nov 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

4 participants