Go Programming Experience

Intermediate

Other Languages Experience

js,java

Related Idea

  • [ ] Has this idea, or one like it, been proposed before?
  • [ ] Does this affect error handling?
  • [ ] Is this about generics?
  • [ ] Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

yes I've seen something similar proposed before (I forget where), but it's a little different

Does this affect error handling?

yes

Is this about generics?

no

Proposal

before:

func getUser() (string, error) {
    txt, err := http.Get()
    if err != nil {
        return "", err
    }
    user, err := createUser()
    if err != nil {
        return "", err
    }
    ...
    return "hahaha", nil
}

after:

func getUser() (string, error) {
    txt, check err := http.Get()
    user, check err := createUser()
    ...
    return "hahaha", nil
}

check err is exactly the same as the following code if err != nil { return nil..., err }

Language Spec Changes

No response

Informal Change

No response

Is this change backward compatible?

y

Orthogonality: How does this change interact or overlap with existing features?

No response

Would this change make Go easier or harder to learn, and why?

No response

Cost Description

No response

Changes to Go ToolChain

No response

Performance Costs

No response

Prototype

No response

Comment From: gabyhelp

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: DeedleFake

This and variants of it have been proposed multiple times before over the years, including at least one proposed by the Go team itself. This particular variant was declined for several different reasons, one of them being that there's no way to modify the error when returning, which is something that should be done most of the time, especially with the introduction of error wrapping in Go 1.13.

Comment From: ianlancetaylor

Thanks, but closing as a duplicate. Perhaps this specific approach has not been proposed before--I'm not sure--but as @DeedleFake says this general approach has been proposed several times and consistently declined.