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: try-catch by assignment #46433

Closed
Cookie04DE opened this issue May 28, 2021 · 6 comments
Closed

proposal: Go 2: try-catch by assignment #46433

Cookie04DE opened this issue May 28, 2021 · 6 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

@Cookie04DE
Copy link

Cookie04DE commented May 28, 2021

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

@gopherbot gopherbot added this to the Proposal milestone May 28, 2021
@zacharyburkett
Copy link
Contributor

I would suggest reviewing these links

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

@seankhliao
Copy link
Member

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

please fill out the language change template

@seankhliao seankhliao changed the title proposal: Write only variable for errors with try catch proposal: Go 2: try-catch by assignment May 28, 2021
@seankhliao seankhliao added error-handling Language & library change proposals that are about error handling. v2 A language change or incompatible library change LanguageChange WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels May 28, 2021
@Cookie04DE
Copy link
Author

I filled out the template.

@sina-devel
Copy link

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

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

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
Copy link
Contributor

No change in consensus.

@golang golang deleted a comment from lxsnum1 Aug 4, 2021
@golang golang locked and limited conversation to collaborators Aug 4, 2022
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

6 participants