proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar

[xiaokentrl]

@apparentlymart
@thediveo

This has nothing to do with me; I'm just putting forward an idea.

package main

import (
    "fmt"
    "io"
    "os"
)

func main() {

    srcFile, err := os.Open("test.txt")
    if err != nil {
        fmt.Println("open source file failed")
    }
    defer srcFile.Close()

    dstFile, err := os.Create("copy.txt")
    if err != nil {
        fmt.Println("create destination file failed")
    }
    defer dstFile.Close()

    _, err = io.Copy(dstFile, srcFile)
    if err != nil {
        fmt.Println("copy file failed")
    }
    
}

Add @error(), and @error().catch{ }

package main

import (
    "fmt"
    "io"
    "os"
)

func main() {

 //demo 1
    srcFile, err := os.Open("test.txt") @error fmt.Println("open source file failed")
    defer srcFile.Close()

    dstFile, err := os.Create("copy.txt") @error( panic )
    defer dstFile.Close()
    _, err = io.Copy(dstFile, srcFile) @error( return "copy file failed" )

 //demo 2
    @error{
        
        srcFile, err := os.Open("test.txt")
        defer srcFile.Close()

        dstFile, err := os.Create("copy.txt")    
        defer dstFile.Close()
        _, err = io.Copy(dstFile, srcFile)
          
    }.catch(err){
        fmt.Println( err )
    }
    
//demo 3
    @error{
        
        srcFile, err := os.Open("test.txt")
        defer srcFile.Close()

        dstFile, err2 := os.Create("copy.txt")    
        defer dstFile.Close()
        
        _, err3 = io.Copy(dstFile, srcFile)
          
    }.catch(err || err2 || err3){
    
        fmt.Println( err )
        fmt.Println( err2 )
        fmt.Println( err3 )

        /*
        
        if err2 != nil {
            panic
        }else{
            recover
        }
        
        */
        
    }

//demo 4
    {
        srcFile, err := os.Open("test.txt")
        defer srcFile.Close()

        dstFile, err2 := os.Create("copy.txt")    
        defer dstFile.Close()
        
        _, err3 = io.Copy(dstFile, srcFile)
          
    }.catch(err || err2 || err3){
    
        fmt.Println( err )
        fmt.Println( err2 )
        fmt.Println( err3 )

        /*
        
        if err2 != nil {
            panic
        }else{
            recover
        }
        
        */
        
    }

//demo 5
    @{
        srcFile, err := os.Open("test.txt")
        defer srcFile.Close()

        dstFile, err2 := os.Create("copy.txt")    
        defer dstFile.Close()
        
        _, err3 = io.Copy(dstFile, srcFile)
          
    }.catch(err || err2 || err3){
    
        fmt.Println( err )
        fmt.Println( err2 )
        fmt.Println( err3 )

        /*
        
        if err2 != nil {
            panic
        }else{
            recover
        }
        
        */
        
    }

}

[renevall]

Ok I will say it, this doesn't look half bad in my eyes. I can see it in some cases while keeping the good old handle your errors in most cases. Still I think the only thing I really want for the future is method chaining for functions returning errors.

[seankhliao]

if you wish to file proposals, please make the effort to fill out the questionnaire and properly explain the semantics. otherwise it's just unclear what we're looking at.

[xiaokentrl]

if you wish to file proposals, please make the effort to fill out the questionnaire and properly explain the semantics. otherwise it's just unclear what we're looking at.

I just occasionally take a look, and I'm not sure if I will use the Go language to develop websites in the future. I really don't care whether the official team adopts it or not, so it's not important to me.

[gophun]

Hi @xiaokentrl, I've noticed this is your sixth error handling proposal you've submitted (#57944, #57957, #63621, #63647, #63961, #64228), with four of them in the past month alone, and none have received significant positive feedback from the community. It might be beneficial to discuss your ideas and share your drafts with others outside the issue tracker before finalizing and filing a proposal.

[thediveo]

The title !err even doesn't match the text using @error and even just @.

[apparentlymart]

Based on this examples, the way I understand the proposal is as follows:

    @error{
        srcFile, err := os.Open("test.txt")
        defer srcFile.Close()

        dstFile, err2 := os.Create("copy.txt")    
        defer dstFile.Close()
        
        _, err3 = io.Copy(dstFile, srcFile)
    }.catch(err || err2 || err3){
        fmt.Println( err )
        fmt.Println( err2 )
        fmt.Println( err3 )
    }

Inside the braces of the @error clause, any non-nil assignment to a local variable whose name is one of the names given in the catch clause parentheses (err, err2, and err3 in this case) causes control to immediately pass to the start of the braces of the catch clause.

In the catch clause, all of the variable names given in the header are implicitly defined, and have assigned to them whatever was assigned to the variable of the same name inside the try clause. Presumably if a declaration of a particular symbol hasn't been reached yet at the time that control diverts into the catch clause, the value is the zero value of whatever type that symbol was declared to have (or implied to have, if using the := syntax) in the try clause.

---

Assuming I understood the above correctly, I think a challenge with this design is that it does not follow any of the existing rules for lexical scoping and symbol visibility in other language features in Go.

For example, a subset of the declarations inside the @error clause seem to be available also in the .catch clause, but there's no common parent block or header element connecting the two, so the relationship is unclear.

This inconsistency with the rest of the language causes some follow-up questions to have unclear answers too. For example, consider the following:

@error{
    err := exampleFallible()
    if anyPredicate {
       // the following line is the main problem...
       err := anotherExampleFallible()
    }
}.catch(err) {
    // ...
}

I've annotated a line saying "the following line is the main problem". That line declares a new symbol err that is local to the scope of the if statement's block.

Does that err also inherit this special treatment of branching into the catch block if it's assigned? Why or why not? What other existing language features behave in a similar way to what you've decided?

I have some other concerns too, but I picked this one as the most significant to raise. This sort of interaction with other parts of the language is why just an example without any explanation of how the spec would change to represent the new feature tends to be an insufficient language proposal, and I expect is part of why the engagement of this and your other similar proposals has been... challenging.

[xiaokentrl]

@apparentlymart
@thediveo

This has nothing to do with me; I'm just putting forward an idea.

[thediveo]

OP upvotes her/his own first post, which might not be in the interest of a helpful proposal triaging process.

[adonovan]

Based on the comments and the voting, and the similarity to previous proposals without addressing their shortcomings, this is a likely decline. Leaving open for a further four weeks for final comment.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[findleyr]

No change in consensus, so declined.
— rfindley for the language proposal review group