proposal: Go 2: call error handling functions with ...

[hauntedness]

Proposal Details

In the current Golang language, error handling requires the use of if statements and return values to check and handle errors. While this approach is effective, it introduces a lot of repetitive code and redundant error handling logic in the codebase. To simplify the error handling process, improve code readability, and maintainability, we propose enhancing the error handling syntax sugar in Golang to make it more concise and flexible.

Background:
In the existing Golang language, error handling is typically done as follows:

func Do(param string) (string, error) {
    return "", nil
}

func DoMany(param string) error {
    result, err := Do(param)
    if err != nil {
        return err
    }
    // Handle result
    return nil
}

This approach requires the use of if statements and return values to check and handle errors, resulting in a lot of repetitive code and redundant error handling logic. To simplify the error handling process, improve code readability, and maintainability, we propose enhancing the error handling syntax sugar in Golang.

Proposal:
We propose introducing the following new syntax sugar to simplify error handling in Golang:

1. Use named optional functions as error handlers:

func check(err error) error {
    return err
}

var nilOrReturn = check

func handle(err error, param string) error {
    return fmt.Errorf("error: %w, param: %s", err, param)
}

2. Support using syntax sugar to handle errors in function calls:

func DoMany(param string) error {
    // 1. regular error handling
    _, err := Do(param)
    if err != nil {
        return check(err)
    }

    // 2. is syntax sugar of 1
    _, err = Do(param)
    nilOrReturn...(err) // flexible naming notation

    // 3. is syntax sugar of 2, perhaps the most use case
    result1, check...err := Do(param)
    fmt.Println(result1)

    // 4. also support multiple params handler
    _, err = Do(param)
    handle...(err, param)

    // -----------------edge cases-------------------
    // 5. allow omit extra parameter?
    _, err = Do(param)
    handle...(err, /*param: default zero? */ )

    // 6. similar to 5, but a little bit make sense
    _, handle...err = Do(param)

    // 7. syntax error? many conflictions
    _, handle...(err, param) = Do(param)

    // 8. not necessary?
    inverseOrder := func(msg string, err error) error {
        return err
    }
    _, err = Do(param)
    inverseOrder...(param, err)
    return nil
}

3. Additional Examples:

func Do2(param string) (string, error) {
    return nil, nil
}

func handle2[T any](err error) (T, error) {
    var t T
    return t, err
}

func handleMore[T any](err error, param string) (T, error) {
    var t T
    return t, fmt.Errorf("error: %w, param: %s", err, param)
}

func DoMany2(param string) (string, error) {
    result, handle2[string]...err := Do2(param)
    return result, nil
}

func DoMore(param string) (string, error) {
    result, err := Do2(param)
    handleMore[string]...(err, param)
    return result, nil
}

Apologies in advance for any lack of thoroughness, any suggestion is appreciated.

[seankhliao]

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

[seankhliao]

I don't think it's clear where the conditional branch went?

[hauntedness]

Would you consider yourself a novice, intermediate, or experienced Go programmer?
experienced.
What other languages do you have experience with?
java,scala,javascript,python,rust
Would this change make Go easier or harder to learn, and why?
harder to learn as introduced new syntax.
Has this idea, or one like it, been proposed before?
yes.
If so, how does this proposal differ?
difference to the keyword approach, check, handle:
this proposal allow to capture more variables than the handle clause.
differ from the leftside function: 52416
the leftside function is immediately return for any error while this proprosal allow us handle the error before return.
Who does this proposal help, and why?
all go developer, the code will be less verbose and repetitive.
What is the proposed change?
see #1.
Please describe as precisely as possible the change to the language.
see #1.
What would change in the language spec?
new feature, see #1.
Please also describe the change informally, as in a class teaching Go.
Is this change backward compatible?
yes
Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
Show example code before and after the change.
What is the cost of this proposal? (Every language change has a cost).
How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
many tools affected, eg: vet, linters, gopls, gofmt
What is the compile time cost?
not sure, but I believe it is small
What is the run time cost?
small cost
Can you describe a possible implementation?
No.
Do you have a prototype? (This is not required.)
How would the language spec change?
Orthogonality: how does this change interact or overlap with existing features?
Yes there will be overlap with existing error handling.
Is the goal of this change a performance improvement?
No
If so, what quantifiable improvement should we expect?
How would we measure it?
Does this affect error handling?
If so, how does this differ from previous error handling proposals?
Is this about generics?
If so, how does this relate to the accepted design and other generics proposals?

[hauntedness]

@seankhliao
The new syntax will either do return or nothing based on the error value. My proposal is below statment will be eventually translated to the idiomatic if err != nil ...

// before
result1, check...err := Do(param)
// after
_, err := Do(param)
if err != nil {
    return check(err)
}

[adonovan]

This seems like another variation on the previous "try" proposal #32437, and it is unclear how it addresses the problems that ultimately caused that proposal to be retracted. Therefore this is a likely decline. Leaving open for a further four weeks for final comments.