proposal: Go 2: add check err goto handler

[noErrorNoLife]

I had an Epiphany last night like this:

func readAllText(path string) string {
	buffer, err := ioutil.ReadFile(path)

	if err != nil {
		goto handler
	}

	return string(buffer)

handler:
	{
		fmt.Println("error: ", err.Error())
		return ""
	}
}

Only the second value is detected each time, and if more than one value is returned, it is recommended to encapsulate it as a type,
If you provide a keyword to detect whether the second variable is nil like this:

a,err := method()
check err goto handler
b,err := method2()
if err != nil{
  // Special error handling...
}
handler:
	{
		fmt.Println("error: ", err.Error())
	}

This makes it compatible with previous or future error handling,Can you solve the problem of error handling
Finally , I'm sorry for my poor English

[beoran]

This seems a bit like "ON ERROR GOTO" in (Visual) Basic. (https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/statements/on-error-statement). If we wanted this in Go, we could perhaps do something like this to stay backwards compatible:

func Foo() {
var err error

goto handler for err // will execute goto handler whenever err becomes non-nil, only error type is allowed.

err = mayFail1()
err = mayFail2()

handler: {
        // do something with err here
        }
}

While "ON ERROR GOTO" is a simple and familiar feature of programming languages, I am undecided whether it is a good feature or not. It overlaps with defer() in some possibly confusing ways.

[noErrorNoLife]

This looks like it's ambiguous?

[ianlancetaylor]

See also #32611 and #34140.

[ianlancetaylor]

It sounds like you are suggesting that we replace

    if err != nil {
        goto handler
    }

with

    check err goto handler

That introduces a new keyword check. In the statement it removes if, != nil, { and }, and a couple of newline characters. That's only a saving of four characters and two newline characters. That doesn't seem like a big enough benefit for a new keyword.

It also makes goto a normal and expected part of error handling. That might be OK, but many people are careful about goto as it can lead to unstructured code.

We also have to consider code like

    f, err := os.Open("x")
    check err goto handler
    s := "str"
handler:
    return s

We don't permit a normal 'goto' to jump over a variable declaration like that, and we probably don't want check err goto to do that either. But that limits the cases in which this technique will work.

[ianlancetaylor]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/bd3ac287ccbebb2d12a386f1f1447876dd74b54d/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!