proposal: Go 2: try-catch by assignment

[Cookie04DE]

Would you consider yourself a novice, intermediate, or experienced Go programmer?

I would consider myself an intermediate Go programmer.

What other languages do you have experience with?

C#, Java, Python, JavaScript

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

I think it would affect the difficulty of learning a medium amount since it adds another flow control mechanism and another special variable (like _).

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

Try/catch has been proposed multiple times but was always declined.

If so, how does this proposal differ?

It not only introduces a try/catch construct but the variable can also act as a must function if it isn't placed in a try/catch since it panics in that case. It also attaches the handling part of the code directly to that, instead of in a handle keyword.

Who does this proposal help, and why?

It reduces boilerplate code and makes Go code more dry.

What is the proposed change?

I propose to a add a write only variable for errors a lot like _. I propose a single character variable like $.
You can write errors to it and if they aren't nil Go panics with the error message.

I also propose a try block. If you write a non nil error to this variable in a try block Go doesn't panic but instead continues execution in the catch block.

Please describe as precisely as possible the change to the language.

It adds the new keywords try, catch and the new write only variable $.
This variable is of type error and if you assign something to it Go checks if the error you provided is nil.
If it isn't the normal flow of instructions is interrupted and depending on if the assignment was made in a try or not either panic is executed or the code in the catch block.
The try keyword expects a code block after it like an if. After that the catch keyword with the variable name for the error in parentheses (catch(err)) with another code block must follow. If the error is to be ignored the parentheses with the variable name can be omitted.

What would change in the language spec?

The spec would now include the try and catch keywords as well as the $ variable.
It would specify how Go reacts when a value is assigned to it.

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

The try block executes it's instructions until a non nil error is passed to $. Once it is the catch part of the try/catch is executed. If the assignment happens outside of a try, Go panics with the error message.

Is this change backward compatible?

Yes, since it only adds a new way to handle errors.

Show example code before and after the change.

Before:

package main

import (
    "log"
    "os"
)

func main() {
    f, err := os.Create("file.txt")
    if err != nil {
       log.Fatal(err)
    }
    _, err = f.Write([]byte("Hello, World!"))
   if err != nil {
       log.Fatal(err)
    }
}

After:

package main

import (
    "log"
    "os"
)

func main() {
    try {
        f, $ := os.Create("file.txt")
        _, $ = f.Write([]byte("Hello, World!"))
    } catch(err) {
        log.Fatal(err)
    }
}

What is the cost of this proposal? (Every language change has a cost).

It requires the introduction of a new flow control structure and the addition of the new variable

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?

All of them since they need to recognize the new variable and flow control structure.

What is the compile time cost?

The cost would be medium since a new flow structure and variable needs to be recognized.

What is the run time cost?

The run time cost would not change since the checks required don't change they just are implicit now instead of explicit.

Can you describe a possible implementation?

A possible implementation would compile assignments to $ as if they were checks for nil and panic/execute the code in catch if so depending on if the assignment is in a try.

Do you have a prototype? (This is not required.)

No.

How would the language spec change?

They would need to include the control flow structure and the variable

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

It does not overlap with any features currently in the language.

Is the goal of this change a performance improvement?

No, since the change is only cosmetic.

Does this affect error handling? If so, how does this differ from previous error handling proposals?

It not only introduces a try/catch construct but the variable can also act as a must function if it isn't placed in a try/catch since it panics in that case. It also attaches the handling part of the code directly to that, instead of in a handle keyword.

I found the following files in Go's source where this syntax could improve the readability:

https://github.com/golang/go/blob/master/src/net/protoconn_test.go#L32
https://github.com/golang/go/blob/master/src/net/udpsock_test.go#L35
https://github.com/golang/go/blob/master/src/net/timeout_test.go#L321
https://github.com/golang/go/blob/master/src/encoding/gob/encoder_test.go#L276
https://github.com/golang/go/blob/master/src/net/internal/socktest/sys_unix.go#L54
https://github.com/golang/go/blob/master/src/crypto/cipher/example_test.go#L27

[zacharyburkett]

I would suggest reviewing these links

#40432
https://github.com/golang/proposal

[seankhliao]

similar to #22122 #32500 #35644 (and many more)

please fill out the language change template

[Cookie04DE]

I filled out the template.

[sina-devel]

I think the try-catch control structure leads to complex code

[ianlancetaylor]

As discussed above, similar ideas have been proposed before, and declined. The emoji voting does not show support for this variation. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

[ianlancetaylor]

No change in consensus.