Why not go one step further and do something like:

result, pass err := someFunc()

instead adding more complexity to the syntax, I’d propose to implement a typical try {} catch (err) {} so we don’t need to capture the function return errors, but they will go directly to the catch if any function in the try returns one.

Example:

Before:

func Parse12To24h(hour12hFormat string) (int, error) {
	t, err := time.Parse("15PM", hour12hFormat)
	if err != nil {
		return -1, err
	}

	return t.Hour(), nil
}

After:

func Parse12To24h(hour12hFormat string) (int, error) {
	try {
		t := time.Parse("15PM", hour12hFormat)
	} catch (err error) {
		return -1, err
	}
	
	return t.Hour(), nil
}

This just saves us time and lines of code, whenever we have to write multiple err != nil checks

It saves about six tokens and two lines. Is that worth the cost of a language change?

As an experienced developer reading a function I am not familiar with, I commonly skim down the page looking at its control flow structure. I look for loops, branches, and return points to get a high level idea of the type of function I am looking at. To identify the return points I currently only need to look for two words, “return” and “panic”. The first is ubiquitous and the second is rare, which means in a practical sense I can quickly scan for lines starting with the word “return.”

The proposed keyword “pass” introduces a new word to look for that would also be ubiquitous. I believe that is a considerable cost. The alternatives of “return if” or “return?” do not incur that cost.

I don’t know how to pronounce “return?” in my mind or when reading code to a colleague, and adding a keyword that contains a non-alpha character is stylistically out of step with the rest of the language.

“return if” seems more natural to me. It has a clear pronunciation when reading and is reminiscent of the “else if” clause already present in the language. But “return if” has the cost that, unlike “if” or “else if”, it takes an error expression instead of a boolean expression. But that cost seems lower than the costs of “pass” or “return?” to me.

Is the cost of adding “return if” worth it to save two lines and maybe some explicit zero values? Maybe. I am generally skeptical of the argument that the repetition of if err != nil { return ... } is a large burden to reading Go code. But this proposal has perhaps the best value/cost ratio we’ve seen so far.

I really like the return if err version of this idea: it directly summarizes the three lines of code that it replaces, and doesn’t introduce any new keywords, logic or anything else other than addressing the one consistent sore point with the existing situation: it takes a lot of space and eyeball friction for such a high-frequency expression. Also, I’ve definitely mistyped err == nil instead of err != nil several times without noticing, so avoiding the need for that is a bonus.

You’ve already tried to change the language to fix this problem, so it seems that there is a general agreement that it is worth fixing, and this is just about as minimal, yet impactful, a change as could be made. If it survives the flamethrowers, it would probably build a good feeling in the community that there really is a willingness to fix the few existing sore points in the language…

How about simply using return to pass errors:

func someFunc() (int, error) {
    f, return := os.Open(filename)

return replaces if err!=nil {return ...,err}, without an explicit declaration of err variable. If you need to wrap the error, handle it, or print, log, etc. you would still use the current error handling boilerplate.

I have to assume this has been proposed before but I did not see it.

Why not take a lesson from if and for and define a version of return that takes a second optional arg, a boolean condition? Return is already special in that there exists a zero-argument form with named returns.

For example; we often write code that passes the error up the stack:

if x, err := foo(); err != nil { 
     return nil, err 
}
// note x and err not available here 

if we allow return to be used as

return nil, err ; err != nil

then you have a short form that short circuits and returns from the function. It doesn’t change the semantics of the return expression to the left of the condition and defers etc work as before. You can mentally read this form of return as return if .

There is added potential to write expressions such as

return x, err := foo() ; err != nil 
// note x and err available here

though this last form may be a step too far.

zero argument returns continue to work, assuming the use of named arguments.

return ; err != nil 

Net introduces no new symbols or keywords and is consistent with for and if

Been thinking about this over the weekend and I was initially attracted to the idea but as I have processed the comments the idea of magically inlining parts of a wrapped function or eating the penalty of value creation and throwing it away feel untenable.

But there’s clearly a problem that needs to be solved otherwise we wouldn’t be banging our heads against it ad infinitum.

@bserdar’s comment doesn’t seem too off base in the service of trying to find a solution even if it is not direct feedback on the solution at hand.

But the overloading of return is a non-starter for me and after reviewing the linked issues, they are all just kinda awkward syntax wise (!! and ? don’t read naturally to my eye). I have been playing with the idea of using a caret (^) as a sentinel value very similar to the underscore (_) to eliminate much of the boilerplate without buying new keywords and flow control or overloading semantics. My thinking is that the underscore means “table the value” and the caret means “send the value back up”.

Looking at xbit’s example in the proposal, here is an equivalent with less trade-offs and language impact…

before:

func newGitRepo(remote string, localOK bool) (Repo, error) {
	r := &gitRepo{remote: remote}
	if strings.Contains(remote, "://") {
		var err error
		r.dir, r.mu.Path, err = WorkDir(gitWorkDirType, r.remote)
		if err != nil {
			return nil, err
		}

		unlock, err := r.mu.Lock()
		if err != nil {
			return nil, err
		}
		defer unlock()

		if _, err := os.Stat(filepath.Join(r.dir, "objects")); err != nil {
			if _, err := Run(r.dir, "git", "init", "--bare"); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
	
			if _, err := Run(r.dir, "git", "remote", "add", "origin", "--", r.remote); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
		}
		r.remoteURL = r.remote
		r.remote = "origin"
	} else {
		if strings.Contains(remote, ":") {
			return nil, fmt.Errorf("git remote cannot use host:path syntax")
		}
		if !localOK {
			return nil, fmt.Errorf("git remote must not be local directory")
		}
		r.local = true
		info, err := os.Stat(remote)
		if err != nil {
			return nil, err
		}
		if !info.IsDir() {
			return nil, fmt.Errorf("%s exists but is not a directory", remote)
		}
		r.dir = remote
		r.mu.Path = r.dir + ".lock"
	}
	return r, nil
}

after:

func newGitRepo(remote string, localOK bool) (Repo, error) {
	r := &gitRepo{remote: remote}
	if strings.Contains(remote, "://") {	
		r.dir, r.mu.Path, ^ = WorkDir(gitWorkDirType, r.remote)

		unlock, ^ := r.mu.Lock()
		defer unlock()

		if _, err := os.Stat(filepath.Join(r.dir, "objects")); err != nil {
			if _, err := Run(r.dir, "git", "init", "--bare"); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
	
			if _, err := Run(r.dir, "git", "remote", "add", "origin", "--", r.remote); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
		}
		
		r.remoteURL = r.remote
		r.remote = "origin"
	} else {
		if strings.Contains(remote, ":") {
			return nil, fmt.Errorf("git remote cannot use host:path syntax")
		}
		if !localOK {
			return nil, fmt.Errorf("git remote must not be local directory")
		}
		r.local = true
		info, ^ := os.Stat(remote)
		
		if !info.IsDir() {
			return nil, fmt.Errorf("%s exists but is not a directory", remote)
		}
		r.dir = remote
		r.mu.Path = r.dir + ".lock"
	}
	return r, nil
}

pass means passing the error up to the caller.

I guess. That doesn’t seem like a natural meaning of “pass” to me, though. The first meaning that jumps to mind for me is to pass over something, meaning to ignore it. Any other opinions on this point?

it is returning the error up to the caller, and given that we already have a keyword that means return it seems like it makes sense to use that, right?

Given that the language already has two forms of return logic (named vs. unnamed), adding a third seems reasonable. The named form already does some “magic” by not directly listing the values returned. This proposed form just adds an additional, logical case that says if you’re returning without achieving the mission of the function, return zero values.

return? maybe seems too “ternary” for the Go language? return if seems like a natural way to say “conditional return” using the existing language elements…

It seems that pass v requires v to have type error and is shorthand for

    if v != nil {
        return ..., v // here ... is the zero value for the other result parameters
    }

It’s unfortunate that error wrapping requires calling the function even when the error is nil, but on the other hand it would not be too hard for the compiler to check whether the wrapper function starts with

    if err == nil {
        return nil
    }

and pull those lines into caller without inlining the whole function.

The name pass is certainly used as a variable name in existing code (e.g., https://golang.org/src/crypto/sha512/sha512_test.go#L664), and that code would break.

Also the name pass doesn’t seem to really describe the operation here. The word “pass” often means to pass over something, but in this case we are–passing it up to the caller? Passing over the rest of the function? I’m not sure.

One possibility would be to use return? or return if instead of pass.

    return? err
    return if err

As you know, there has been a lot of discussion about error handling in Go. Is this language change big enough for the problem? It saves about six tokens and two lines. Is that worth the cost of a language change?

Seems slightly unfortunate that we always have to call the errors.Wrap function even when there is no error.

1. executing code in case of error

I don’t know if this is necessary, actually. If any extra code needs to be run, I think that it’s fine to just use if err != nil { ... } like you would now. I think that a shorter syntax is fine if it only covers the common case of doing nothing but returning a potentially modified err. In fact, it might be better if it does simply so that it doesn’t completely supplant the existing syntax and introduce non-orthogonal features.

That being said, I do not like the pass syntax at all. It introduces a new keyword, which breaks backwards compatibility, it’s hard to read when doing anything to the error before returning, and it doesn’t solve the basic issue of requiring new variables for every call that might return an error.

Honestly, I’m leaning more and more towards some kind of limited macro system to deal with this. If a macro system could be sufficiently powerful to allow you to wrap an arbitrary call that returns T, error, and that call is itself used in a larger expression, and the usage of the macro causes a return of a modified error when the error isn’t nil, it solves all of the issues. If the user can define the handler macros both inline and globally, then there could be clean, reusable utility macros for common cases and more specific ones defined inline for more specific cases. For example,

func ContrivedExample(s1, s2 string) (int, error) {
  macro toInt { ... } // Bikeshedding purposefully omitted.
  return toInt(s1) + toInt(s2), nil
}

And yes, I am aware that this actually does allow arbitrary extra code, despite my first paragraph up above.

I dont like pass overlapping with return. I think pass should be used in a specific context and in a uniform way.

Here a few other ideas:

// 1.
result, pass := someFunc()

result, pass fmt.Errorf("adding more context: %v", err) := someFunc() 

// 2.
result := someFunc() pass

result := someFunc() pass fmt.Errorf("adding more context: %v", err)

However, i think we have to think about 3 things when handling errors:

1. a simple return
2. adding extra context
3. executing code in case of error

The pass solution wont handle the 3rd case (and depending of the chosen solution, not even the 2nd), and another solution would have to come in. And maybe go community would not like many different ways to handle errors.

That’s why i think a catch solution like this would be more appropriate, because it would give us a single, uniform way to handle errors in all those cases.

“return if” seems more natural to me. It has a clear pronunciation when reading and is reminiscent of the “else if” clause already present in the language. But “return if” has the cost that, unlike “if” or “else if”, it takes an error expression instead of a boolean expression. But that cost seems lower than the costs of “pass” or “return?” to me.

The cost of an error expression instead of a boolean expression after return if is high in my opinion. It can be a bit confusing because of the if keyword.

return if nil, sounds like saying return if the result of the expression is nil but that statement does the opposite. Which is why I think “pass”, “return?” or something else may be better.

I haven’t seen anybody try to address this point: It saves about six tokens and two lines. Is that worth the cost of a language change?

I think several comments tried to address this: the main complaint is that the current solution is a) very high frequency; and b) takes 3 lines. Doing the math, eliminating 2 lines would save a lot of lines over the entire Go codebase (someone could presumably compute exactly how many – it might be a remarkably large number – anyone familiar with that Go language analysis tool that someone posted a few months back on the go-nuts list?).

One of the arguments against the try proposal (#32437) was that it introduced another kind of flow of control. This same consideration arises with this proposal.

this is why I favor the return if syntax because it minimizes this concern: it is just a shorthand way of expressing the exact same control flow that everyone is familiar with. Its only point is to save those 2 lines!

The compiler optimization @xbit mentions above is just that: a compiler optimization, but not fundamentally a new flow control.

The more I think about it, the more I like the way errors are currently handled in Go.

IMO, return? sounds great in theory, but in practice, I have a feeling it’ll make reading the code harder.

Not just that, but ignoring other use cases, for error handling, all this is doing is removing the need for writing if err != nil { and }.

Let’s say that this is sufficient in term of error handling and we decide to go with return? or return if, then we’re met with the fact that since we’re using something as generic as the keyword return, return? will need to support returning multiple values - not just one.

To do that, return? would need to have an extra argument - a condition, which like I said earlier, will most likely make the code harder to read.

Unlike what @DeedleFake mentioned, I don’t think the default behavior should be checking if the first argument is nil, because if return? is to work with values other than error, then what happens with values that cannot be nil (i.e. string)?

This leaves us with the following:

something, err := getSomething()
return? err != nil, nil, err 
return something, nil

I think that this is a downgrade from the existing:

something, err := getSomething()
if err != nil {
    return nil, err 
}
return something, nil

Even though there’s more LoC, at least there’s no confusion, and the number of returned values match with the function signature.

Also, the examples used for the return? condition all have a conveniently small conditions, but take something like this as example:

func ValidatePassword(password string) (bool, error) {
	if len(password) < MinPasswordLength {
		return false, fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	}
	if len(password) > MaxPasswordLength {
		return false, fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	}
	return true, nil
}

With return?, we’d have this instead:

func ValidatePassword(password string) (ok bool, err error) {
	return? len(password) < MinPasswordLength, false, fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	return? len(password) > MaxPasswordLength, false, fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	return true, nil
}

It looks nice, but the lines are quite a bit longer - and there’s just two values being returned.

Personally, with named parameters, it’d look even better:

func ValidatePassword(password string) (ok bool, err error) {
	if len(password) < MinPasswordLength {
		err = fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	} else if len(password) > MaxPasswordLength {
		err = fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	} else {
		ok = true
	}
	return
}

But I digress.

That said, I think the suggestion for pass has its merits, but more importantly, it’s targeted at error handling, whereas return? has a wider implications that also happens to be something that can be leveraged for error handling.

As @ianlancetaylor mentioned, I also think that the word pass might be inappropriate for this use case. pass does not convey “pass this value to the caller if the value passed is not nil”. assert or check would make more sense for me, but even these two don’t feel explicit enough to me.

Your version of WriteFile is wrong. While the original function will always close the file, your version will return if there is an error in f.Write or n<len(data) without closing the file. You could use defer, but then you will miss the error returned by f.Close. At the end, I think you would only be able to replace thee first return, so this may not be the most compelling example.