proposal: Go 2: conditional return for better error handling

[omeid]

The issue of simplifying error handling is nothing new and it has come up many times, there has been various proposals on the topic as well, (e.g., #16225, #18721, #21146, #21155, and more comprehensively #21161).

The general complaint that too much Go code contains these lines or a variation of it.

if err != nil {
    return err
}

This proposal suggests the addition of conditional return statement as outlined below:

ConditionalReturnStmt = "return" ( Expression ) [ ExpressionList ]
Where the value of Expression is tested for equality with predeclared untyped value nil to determine whatever the return expression should result in the termination of the function. Similar to ReturnStmt, it may optionally provide one or more result values instead of the Expression.

This would allow writing code like so:

 return(err)

or given:

func Chdir(dir string) error {
	if e := syscall.Chdir(dir); e != nil {
		return &PathError{"chdir", dir, e}
	}
	return nil
}

Would become:

func Chdir(dir string) error {
	e := syscall.Chdir(dir); 
        return(e) &PathError{"chdir", dir, e}
	return nil
}

Though, I am not sure how one could use a Conditional Return as is or make it work with a situation like the following:

func dialPlan9Blocking(ctx context.Context, net string, laddr, raddr Addr) (fd *netFD, err error) {
	if isWildcard(raddr) {
		raddr = toLocal(raddr, net)
	}
	f, dest, proto, name, err := startPlan9(ctx, net, raddr)
	if err != nil {
		return nil, err
	}
	_, err = f.WriteString("connect " + dest)
	if err != nil {
		f.Close()
		return nil, err
	}
	data, err := os.OpenFile(netdir+"/"+proto+"/"+name+"/data", os.O_RDWR, 0)
	if err != nil {
		f.Close()
		return nil, err
	}
	laddr, err = readPlan9Addr(proto, netdir+"/"+proto+"/"+name+"/local")
	if err != nil {
		data.Close()
		f.Close()
		return nil, err
	}
	return newFD(proto, name, nil, f, data, laddr, raddr)
}```

If similar discussion has been done, please feel free to close the issue.

[ianlancetaylor]

It would be useful to see a reference to the error handling design draft mentioned at https://go.googlesource.com/proposal/+/master/design/go2draft.md .

[networkimprov]

Also, recent discussion of error handling is mostly on the wiki
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

[ianlancetaylor]

The proposed syntax is ambiguous. You can already write return (err), meaning to return the value err. This adds a condition that doesn't look like a condition. We aren't going to do this. Closing in favor of the general error handling discussion linked from https://go.googlesource.com/proposal/+/master/design/go2draft.md .

[omeid]

The proposed syntax is ambiguous.

The syntax is the least of concerns and doesn't have to be so.

This adds a condition that doesn't look like a condition.

I don't see how this is different from the purposed check.

The general idea of something similar to swift's guard is perhaps worth considering along with the suggested exception-like check-handler mechanism.

I am a little reluctant to write a proposal as error handling discussion seems to have progressed and the core team have some good idea of what it is going to be like.