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

Jump to bottom

proposal: Go 2: conditional return for better error handling #28229

Closed
omeid opened this issue Oct 16, 2018 · 4 comments
Closed

proposal: Go 2: conditional return for better error handling #28229

omeid opened this issue Oct 16, 2018 · 4 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@omeid
Copy link

omeid commented Oct 16, 2018 •
edited

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.
@gopherbot gopherbot added this to the Proposal milestone Oct 16, 2018
@ianlancetaylor ianlancetaylor added LanguageChange v2 A language change or incompatible library change labels Oct 16, 2018
@ianlancetaylor ianlancetaylor changed the title proposal: Go 2: Condition Return for better Error Handling proposal: Go 2: conditional return for better error handling Oct 16, 2018
@ianlancetaylor
Copy link
Contributor

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

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

@ianlancetaylor
Copy link
Contributor

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

omeid commented Jun 18, 2019 •
edited

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.

@bradfitz bradfitz added the error-handling Language & library change proposals that are about error handling. label Oct 29, 2019
@golang golang locked and limited conversation to collaborators Oct 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
5 participants
@bradfitz @networkimprov @omeid @ianlancetaylor @gopherbot