discussion: spec: reduce error handling boilerplate using ?

[ianlancetaylor]

This is a discussion about a new syntax that may be used to handle errors. This is issue #71203 converted into a discussion.

I've written a tool that converts ordinary Go code into code that uses the syntax from the proposal at #71203. That tool is available at https://go.dev/cl/643996. In order to build and use it you must first apply the changes in the patch series ending at https://go.dev/cl/642502.

Using that tool, I've converted much of the standard library to the new syntax. This can be seen at https://go.dev/cl/644076.

I encourage people interested in this proposal to take a look at these changes. Please consider whether the new code is more or less clear to the reader. Please consider whether the code logic stands out more clearly when there is less syntax devoted to error handling.

Most importantly, please avoid preconceptions when looking at this code. I'm not insisting that this change is better. But if you look at the changed code having already decided that this proposal is a bad idea, we won't learn anything. Really try to see whether the new code is better or worse.

If you choose to comment on how this proposal affects the standard library, please show specific examples to demonstrate your point. Don't argue in the abstract; look at real uses of real code.

The rest of this comment is largely a copy of #71203, partly updated, with some parts omitted.

Background

See #71203 for more background.

The goal of this proposal is to introduce a new syntax that reduces the amount of code required to check errors in the normal case, without obscuring flow of control.

New syntax

This section is an informal description of the proposal, with examples. A more precise description appears below.

I propose permitting statements of the form

	r, err := SomeFunction()
	if err != nil {
		return fmt.Errorf("something failed: %v", err)
	}

to be written as

	r := SomeFunction() ? {
		return fmt.Errorf("something failed: %v", err)
	}

The ? absorbs the error result of the function. It introduces a new block, which is executed if the error result is not nil. Within the new block, the identifier err refers to the absorbed error result.

Similarly, statements of the form

	if err := SomeFunction2(); err != nil {
		return fmt.Errorf("something else failed: %v", err)
	}

may be written as

	SomeFunction2() ? {
		return fmt.Errorf("something else failed: %v", err)
	}

Further, I propose that the block following the ? is optional. If the block is omitted, it acts as though there were a block that simply returns the error from the function. For example, code like

	if err := SomeFunction2(); err != nil {
		return err
	}

may in many cases be written as

	SomeFunction2() ?

Formal proposal

This section presents the formal proposal.

An assignment or expression statement may be followed by a question mark (?). The question mark is a new syntactic element, the first permitted use of ? in Go outside of string and character constants. The ? causes conditional execution similar to an if statement. A ? at the end of a line causes a semicolon to be automatically inserted after it.

A ? uses a value as described below, referred to here as the qvalue.

For a ? after an assignment statement, the qvalue is the last of the values produced by the right hand side of the assignment. The number of variables on the left hand side of the assignment must be one less than the number of values produced by the right hand side (the right hand side values may come from a function call as usual). It is not valid to use a ? if there is only one value on the right hand side of the assignment.

For a ? after an expression statement the qvalue is the last of the values of the expression. It is not valid to use a ? after an expression statement that has no values.

The qvalue must be of interface type and must implement the predeclared type error; that is, it must have the method Error() string. In most cases it will simply be of type error.

A ? is optionally followed by a block. The block may be omitted if the statement using ? appears in the body of a function, and the enclosing function has at least one result, and the qvalue is assignable to the last result (this means that the type of the last result must implement the predeclared type error, and will often simply be error).

Execution of the ? depends on the qvalue. If the qvalue is nil, execution proceeds as normal, skipping over the block if there is one.

If the ? is not followed by a block, and the qvalue is not nil, then the function returns immediately. The qvalue is assigned to the final result. If the other results (if any) are named, they retain their current values. If they are not named, they are set to the zero value of their type. The results are then returned. Deferred functions are executed as usual.

If the ? is followed by a block, and the qvalue is not nil, then the block is executed. Within the block a new variable err is implicitly declared, possibly shadowing other variables named err. The value and type of this err variable will be those of the qvalue.

That completes the proposal.

Discussion

This new syntax is partly inspired by Rust's question mark operator, though Rust permits ? to appear in the middle of an expression and does not support the optional block. Also, I am suggesting that gofmt will enforce a space before the ?, which doesn't seem to be how Rust is normally written.

Absorbing the error returned by a function, and optionally returning automatically if the error is not nil, is similar to the earlier try proposal. However, it differs in that

• ? is an explicit syntactic element, not a call to a predeclared function, and
• ? may only appear at the end of the statement, not in the middle of an expression.

Declaring the err variable

As discussed above, when a block follows the ? it implicitly declares a new err variable. There are no other cases in Go where we implicitly declare a new variable in a scope. Despite that fact, I believe this is the right compromise to maintain readability while reducing boilerplate.

A common suggestion among early readers of this proposal is to declare the variable explicitly, for example by writing

	r := SomeFunction() ? err {
		return fmt.Errorf("something failed: %v", err)
	}

In practice, though, the variable would essentially always be simply err. This would just become additional boilerplate. Since the main goal of this proposal is to reduce boilerplate, I believe that we should try our best to do just that, and introduce err in the scope rather than requiring people to declare it explicitly.

If the implicit declaration of err seems too problematic, another approach would be to introduce a new predeclared name. The name err would not be appropriate here, as that would be too often shadowed in existing code. However, a name like errval or erv would work. Within a ? optional block, this name would evaluate to the qvalue. Outside of a ? optional block, referring to the name would be a compilation error. This would have some similarities to the predeclared name iota, which is only valid within a const declaration.

A third approach would be for errval or erv to be a predeclared function that returns the qvalue.

Supporting other types

As discussed above the qvalue must be an interface type that implements error. It would be possible to support other interface types. However, the ? operator, and especially the implicitly declared err variable, is specifically for error handling. Supporting other types confuses that focus. Using ? with non-error types would also be confusing for the reader. Keeping a focus on just handling errors seems best.

It would also be possible to support non-interface types that implement error, such as the standard library type *os.SyscallError. However, returning a value of that type from a function that returns error would mean that the function always returns a non-nil error value, as discussed in the FAQ. Using different rules for ? would make an already-confusing case even more confusing.

Effects on standard library

See https://go.dev/cl/644076.

The latest version of the conversion tool found 723,292 statements in the standard library. It was able to convert 14,304 of them to use ?. In all, 1.98% of all statements were changed. 2,825 statements, or 0.39% of the total, were changed to use a ? with no optional block.

In other words, adopting this change across the ecosystem would touch an enormous number of lines of existing Go code. Of course, changing existing code could happen over time, or be skipped entirely, as current code would continue to work just fine.

Pros and cons

Pros

Advantage 1: Rewriting

	r, err := SomeFunction()
	if err != nil {
		return fmt.Errorf("something failed: %v", err)
	}

to

	r := SomeFunction() ? {
		return fmt.Errorf("something failed: %v", err)
	}

reduces the error handling boilerplate from 9 tokens to 5, 24 non-whitespace characters to 12, and 3 boilerplate lines to 2.

Rewriting

	r, err := SomeFunction()
	if err != nil {
		return err
	}

to

	r := SomeFunction() ?

reduces boilerplate from 9 tokens to 1, 24 non-whitespace characters to 1, and 3 boilerplate lines to 0.

Advantage 2: This change turns the main code flow into a straight line, with no intrusive if err != nil statements and no obscuring if v, err = F() { … } statements. All error handling either disappears or is indented into a block.

Advantage 3: That said, when a block is used the } remains on a line by itself, unindented, as a signal that something is happening. (I'm also listing this as a disadvantage, below.)

Advantage 4: Unlike the try proposal and some other error handling proposals, there is no hidden control flow. The control flow is called out by an explicit ? operator that can't be in the middle of an expression, though admittedly the operator is small and perhaps easy to miss at the end of the line. I hope the blank before it will make it more visible.

Advantage 5: To some extent this reduces a couple of common error handling patterns to just one, as there is no need to decide between

	var (
		v   string
		err error
	)
	if v, err = F(); err != nil {
		...
	}

and

	v, err := F()
	if err != nil {
		...
	}

Instead people can consistently write

	v := F() ? {
		...
	}

Cons

Disadvantage 1: This is unlike existing languages, which may make it harder for novices to understand. As noted above it is similar to the Rust ? operator, but still different. However, it may not be too bad: Todd Kulesza did a user study and discovered that people unfamiliar with the syntax were able to see that the code had to do with error handling.

Disadvantage 2: The shadowing of any existing err variable may be confusing. Here is an example from the standard library where the ? operator can not be easily used:

fmt/scan.go:

	for n = 1; !utf8.FullRune(r.buf[:n]); n++ {
		r.buf[n], err = r.readByte()
		if err != nil {
			if err == io.EOF {
				err = nil // must change outer err
				break
			}
			return
		}
	}
	// code that later returns err

In this example the assignment err = nil has to change the err variable that exists outside of the for loop. Using the ? operator would introduce a new err variable shadowing the outer one. (In this example using the ? operator would cause a compiler error, because the assignment err = nil would set a variable that is never used.)

Disadvantage 3: When using a block, the } remains on a line itself, taking up space as pure boilerplate. (I'm also listing this as an advantage, above.)

Disadvantage 4: No other block in Go is optional. The semicolon insertion rule, and the fact that a block is permitted where a statement is permitted, means that inserting or removing a newline can convert one valid Go program into another. As far as I know, that is not true today.

For example, these two functions would both be valid and have different meanings, although the only difference is whitespace.

func F1() error {
	err := G1()
	log.Print(err)
	G2() ?
	{
		log.Print(err)
	}
	return nil
}

func F2() error {
	err := G1()
	log.Print(err)
	G2() ? {
		log.Print(err)
	}
	return nil
}

Disadvantage 5: For an expression statement that just calls a function that returns an error, it's easy to accidentally forget the ? and write F() rather than F() ?. Of course it's already easy to forget to check the error result, but once people become accustomed to this proposal it may be easy to overlook the missing ? when reading code.

Disadvantage 6: This proposal has no support for chaining function calls, as in F().G().H(), where F and G also have an error result.

Disadvantage 7: This proposal makes it easier to simply return an error than to annotate the error, by using a plain ? with no block. This may encourage programmers to skip error annotations even when they are desirable.

Disadvantage 8: We really only get one chance to change error handling syntax in Go. We aren't going to make a second change that touches 1.5% of the lines of existing Go code. Is this proposal the best that we can do?

Disadvantage 9: We don't actually have to make any changes to error handling. Although it is a common complaint about Go, it's clear that Go is usable today. Perhaps no change is better than this change. Perhaps no change is better than any change.

Transition

If we adopt this proposal, we should provide tools that can be used to automatically rewrite existing Go code into the new syntax. Not everyone will want to run such a tool, but many people will. Using such a tool will encourage Go code to continue to look the same in different projects, rather than taking different approaches. This tool can't be gofmt, as correct handling requires type checking which gofmt does not do. It could be an updated version of go fix. See also modernizers.

We will have to update the go/ast package to support the use of ?, and we will have to update all packages that use go/ast to support the new syntax. That is a lot of packages.

We will also have to update the introductory documentation and the tour. And, of course, existing Go books will be out of date and will need updating by their authors. The change to the language and compiler is the easiest part of the work.

[ianlancetaylor]

Thumbs-up this thread if you think that it's worth considering a language change for a simpler error-handling syntax that reduces boilerplate.

Thumbs-down this thread if you think that the current syntax is good enough, and that it's not worth changing the language.

Note that this is only asking about syntax, not about other error-handling issues such as accidentally ignoring errors.

Please don't use this thread to discuss syntax changes other than the ones in this proposal. This discussion is about a specific proposal; please do not start discussing the hundreds of other error handling proposals.

[alex-klimov]

these if statements make it quite cumbersome to find the happy path of the code as it adds a lot of noise to the code you're trying to understand/work on

I'd argue the only meaningful noise reduction given through this proposal is the naked ? used to signify a straightforward error return, and I'd question if the 3-line if statement doing the verbose error return that would be replaced is introducing any significant barrier to readability. The ? followed by a block is arguably equally semantically noisy, just with fewer tokens.

The most valuable part in this proposal is indeed naked ?. Its behavior is very straightforward, and its purpose is to remove copy-pasting of exactly the same three lines of code, which hopefully never change, in the middle-chain of calls. Those are the calls that simply carry the error from where it has started to the place where it would be logged and/or processed.

The problem with having the exact the same three line of code in the middle call chain - as long as they are there and explicit, they MIGHT change. So careful examination of them is needed. They are not free even to a trained eye.

This change could be one of the most positively impactful for Go language by addressing one of the most critical pain points with the language.

[tim-upguard]

If those three lines are so ubiquitous, repetitive and a critical pain point, it can be solved today without changing the language at all. Language syntax is not the first place to go making such a change. There are user-land options for the pain point being raised. Implement it in an editor extension. Fork an existing one if you like!

1. You could use the editor's code folding feature to automatically collapse error blocks that match that repetitive pattern
2. You could customise the syntax highlighting to have fainter colours for the repetitive error handling blocks to give them less visual importance (I'm assuming the sentiment that some people feel it's visually "less important" because it's being labelled as noise)

[mukunda-]

Just adding my two cents. I believe this is not solved today because a lot of us expect this "critical pain point" to be solved in the language itself at some point. Which it should be. Adding "err != nil...return err" everywhere frankly looks awful. Working on additional tooling to handle this boilerplate is getting into the territory of TypeScript, and, after working with the "templ" templating engine, I can easily see that additional tooling is a nightmare to get right.

What I am often tempted to do today is wrap errors in panics so I can localize this mess and not do error bubbling boilerplate literally everywhere. When working with I/O, 25% of the code is err checking boilerplate. None of the code is concerned with what the error is. The errors happen rarely and are usually unrecoverable. I just want to exit the function and move on. Seeing this proposal is a light at the end of a tunnel, a very long tunnel created by 3 ubiquitous lines of code.

[JetSetIlly]

If those three lines are so ubiquitous, repetitive and a critical pain point, it can be solved today without changing the language at all. Language syntax is not the first place to go making such a change. There are user-land options for the pain point being raised. Implement it in an editor extension. Fork an existing one if you like!

1. You could use the editor's code folding feature to automatically collapse error blocks that match that repetitive pattern

I'm so glad you've mentioned this. That's exactly what I've been thinking about too. I think this is a presentation problem.

I tried implementing the block collapse idea in vim but wasn't entirely satisfied with the results so I gave up. But it is still an avenue worth exploring I think.

edit: I still think Ian's initial proposal is useful in such a solution though. The collapsed view of the error would go from

if r, err := foo(); err != nil {
    return err
}

to

r := foo() ?

etc. You can do that with text editors today. Handling more complex error blocks would be possible too.

[alex-klimov]

If those three lines are so ubiquitous, repetitive and a critical pain point, it can be solved today without changing the language at all. Language syntax is not the first place to go making such a change. There are user-land options for the pain point being raised. Implement it in an editor extension. Fork an existing one if you like!

For me Go is one of the tools to use to solve a problem. Go has many great qualities, and it is popular tool for a reason. Like any tool - it also has flaws, which sometimes limit tool usefulness. The flaw with error checking is popular one for a reason as well. Some flaws can be fixed, some flaws can be mitigated.

I'm not religious about my tools. If I need to invest more energy in mitigating the problem caused by the tool, than a tool saves me when solving original problem - I pick another tool if it exists.

1. You could use the editor's code folding feature to automatically collapse error blocks that match that repetitive pattern
2. You could customise the syntax highlighting to have fainter colours for the repetitive error handling blocks to give them less visual importance (I'm assuming the sentiment that some people feel it's visually "less important" because it's being labelled as noise)

This is a good idea, and it will mitigate the problem if done well. It needs to work well with debugging and work across IDEs used by my team.

It will not solve the problem though entirely. Code reviews, for example, will still be impacted, unless visualizations in code diff tool are updated as well.

Proposal has a potential to solve the problem instead of mitigating it. I'm very interested in fixing this flaw, because Go is a good tool.

[ianlancetaylor]

Thumbs-up this thread if you think the proposed implicit declaration of an err variable is acceptable.

Thumbs-down this thread if you think that implicit err is a bad idea, but that a predeclared erv identifier would be acceptable.

Use the confused emoji (😕 ) if you think that neither implicit err nor erv are OK, but that an explicit err declaration, such as f := os.Open("f") ? err { return fmt.Errorf("wrap %v", err) } would be OK.

[boomlinde]

Explicit declaration of an error name addresses a couple of (IMO) major issues with the proposal. First, you could no longer implicitly shadow another err. Second, it avoids the semicolon insertion issue and the potential for subtle errors when the block is entered on a new line; F() ? err on its own is incorrect, err { on its own line is incorrect.

This proposal would also be the first time in the language (that I know of) where a variable can enter a scope without being explicitly declared elsewhere. Consider implications on readability and editor ergonomics. How do I go to its definition? What should I search for to find my way to the source of the error?

With implicit naming, you will also end up with more boilerplate in some cases where there are nested error conditions. Perhaps not often enough to be a deal breaker in itself, but certainly worth consideration.

I personally don't really care that much about the boilerplate. The main issue I have with Go's error handling as it is now is that it's often necessary to pollute the scope with errors that you only consider exactly once, immediately after calling the function that returned it. This proposal would address that and has some value to that end, even if the stated purpose is to reduce boilerplate.

[mikeschinkel]

Explicit declaration of an error name addresses a couple of (IMO) major issues with the proposal. First, you could no longer implicitly shadow another

I am not sure I follow you on this line of thought. How does explicit keep from shadowing another variable?

 1. var err error 
 2. // other code 
    .......
24. // more code 
25. value, err := doSomething() ? {
26.    return errors.Join(err,fmt.Errorf("doSomething failed"))
27. }

Doesn't err on line 25 and 26 shadow err on line 1?

[boomlinde]

It doesn't prevent shadowing another variable. It prevents you from doing so through the mere coincidence that the implicit name of the error variable in the ? block happens to be the same as some other variable in the outer scope. The difference is particularly important when you are dealing with nested error conditions.

I'll add that I am thinking more along the lines of

value := doSomething() ? err {
    return errors.Join(err, fmt.Errorf("doSomething failed"))
}

[sebwalle]

Explicit declaration of an error name addresses a couple of (IMO) major issues with the proposal. First, you could no longer implicitly shadow another

I am not sure I follow you on this line of thought. How does explicit keep from shadowing another variable?

 1. var err error 
 2. // other code 
    .......
24. // more code 
25. value, err := doSomething() ? {
26.    return errors.Join(err,fmt.Errorf("doSomething failed"))
27. }

Doesn't err on line 25 and 26 shadow err on line 1?

The big difference is you explicitly do it and can choose a new name for the error at line 25 if you need to reference the err on line 1 if you want to.

[AndrewHarrisSPU]

Here's something I found ridiculous/amusing but also interesting:

I was spelunking for tough cases of long functions with defers, named parameters, nested scoping and https://go-review.googlesource.com/c/go/+/644076/1/src/net/http/client.go offered a good example at line 589, func (c *Client) do(req *Request) (retres *Response, reterr error). (FWIW, IMHO, this is doing a good thing already, the name reterr is way better than err for a method as involved as do).

Here's where I had a light bulb moment (not necessarily a good one):

(0) line 642: var err error
line 643, 667: non-trivial block-?s that shadow 642
(A) line 690: err = c.checkRedirect(req, reqs)
(B) line 695 to 697: matching err on a specific value
(C) line 704 to 708: tidy up some things
(D) line 710 to 717: finally err ? test, handling an edge case

I took a quick stab at rewriting (A) c.checkRedirect(req, reqs) ? { --(B)-- --(C)-- --(D)-- }, seconds later realizing this doesn't quite work - (C) should execute whether (A) returns an error or not.

The distance between line 642 and (A) is a bit much. (0) could appear immediately before (A). The right solution currently is probably doing this.

If the further goal is to isolate (A)'s err from wider scope, just using naked { --(0)-- --(A)-- --(B)-- --(C)-- --(D)-- } would work. But maybe it's not clear why the scope is being introduced, or at least not conventional.

With this proposal I believe this would also work:

new(error) ? {
    --(A)--
    --(B)--
    --(C)--
    --(D)--
}

Which strikes me as a bit ridiculous but on the other hand intriguing, riffing on ? as establishing better scoping of err.

[ianlancetaylor]

Thumbs-up this thread if you think it's OK to have ? followed by an optional block.

Thumbs-down this thread if you think it's OK to have ? with no block, but that the optional block is not a good idea. In other words, that it's useful to support returning from the function, but it's not necessary to support annotating the error or taking any action other than returning. (This also of course means that there is no implicit err or erv variable.)

[apparentlymart]

@mikeschinkel I expect this answer differs considerably depending on which examples you are looking at and and so I'm certainly not meaning to suggest that it's a net benefit for all cases, but I can say that as I reviewed the results of running Ian's transformation tool over a few different codebases I work on regularly there were far more examples where the transformed version had less shadowing of err rather than more, and a large number of cases where after transformation there was no err in the main scope at all anymore.

The implicit nature of the err symbol in the current proposal is a concern for me, but that already has its own thread #71460 (comment) where at the time I'm writing this the emoji voting is strongly in favor of making the symbol name explicit, and so for the sake of all of these other threads I'm presuming the proposal is likely to be modified in that way in a future draft.

I don't want to overwhelm this comment with dozens of examples, but I took a quick re-skim of the examples and found one that I considered favorable with regard to shadowing. In the original form of this code, the main scope err was reassigned four times, and was shadowed by another err inside the if config.UseAzureADAuthentication branch. In the new code there is no err in the main scope at all, and no shadowing of any error variables.

This is just one example, but at least for me this seems the most common outcome.

[mukunda-]

I'm voting 👍 just because I like quality of life things. I think the benefit here is extremely minimal though. Avoiding cluttering the scope with err variables is nice, but nothing to warrant large complexity like this.

[mikeschinkel]

@apparentlymart — That example does not annotate the errors — which I find problematic in all cases — so assuming that every error is annotated then we have something different:

armConfig, err := builder.Build() ? {
  return nil, fmt.Errorf("Error building ARM Config: %w", err)
}
oauthConfig, err := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ? {
  return nil, fmt.Errorf("Error building OAuth Config: %w", err)
}
hamiltonEnv, err  := environments.EnvironmentFromString(config.Environment) ? {
  return nil, fmt.Errorf("Error getting environment: %w", err)
}

Now the obvious argument here is that the variable gets shadowed, but I think forcing the error to be assigned to a magicly named err var with block scope is treating the symptom, not the actual problem.

The actual problem is a different issue in the Go language that IMO really should be addressed. The problem there is that you can write multiple declaration+assignment statements (:=) using the same name for err — which is allowed but should not have been IMO — because doing so shadows the err variable which often unintended. This is a problem I have been wanting to bring up for a long time but this give me a good reason to address it here.

Imagine if instead we could tell Go that the an err variable has already been declared and thus should not be shadowed? The following example uses an @ prefix for a variable to indicate is should only be assigned, not declared unless it has not been declared (let's not bikeshed the syntax and instead discuss the concept first.)

armConfig, @err := builder.Build() ? {
  return nil, fmt.Errorf("Error building ARM Config: %w", err)
}
oauthConfig, @err := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ? {
  return nil, fmt.Errorf("Error building OAuth Config: %w", err)
}
hamiltonEnv, @err  := environments.EnvironmentFromString(config.Environment) ? {
  return nil, fmt.Errorf("Error getting environment: %w", err)
}

This approach does not stop potential shadowing when the @ is not used, but if what I am proposing here was adopted then I could see it become a best practice to always prefix your error variables with @. This BTW, should also apply for type assertions and map accesses as well:

foo, @ok := Foos[fooKey]
bar, @ok := Value().(Bar)

---

Now we could potentially have the following code — and that would be an improvement — but I argue it would ONLY be an improvement if Go were to automatically join any errors with an error that provides detailed error information including filename, line number, package name, type name if applicable, func name, and a map of pointers to all variables in scope when the error occurred. That would greatly reduce the need to annotate errors and thus make the naked ? option more palatable.

armConfig := builder.Build() ?
oauthConfig := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ?
hamiltonEnv  := environments.EnvironmentFromString(config.Environment) ?

---

Still, I noticed something I consider troublesome from the examples you shared and that is that the ? if used without the optional block could easily be missed if the line is so long that it is currently not being displayed in the edit window. This tends to make me think using a naked ? should be a non-starter, and that adding a try prefix to the ? suffix on this proposal would be a better solution:

try armConfig := builder.Build() ?
try oauthConfig := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ?
try hamiltonEnv  := environments.EnvironmentFromString(config.Environment) ?

---

And finally, the problem with the block-scope approach proposed is that it narrows the ways in errors can be handled to include effectively only early return, unless the developer wants to add even more boilerplate. To address that I would really like to see gotoadded as an option to the naked version and the block version along with a new error() function (or errorinfo() if error() cannot be used:

armConfig, @err := builder.Build() ? goto err
oauthConfig, @err := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ? goto err
hamiltonEnv, @err  := environments.EnvironmentFromString(config.Environment) ? goto err
err:
  return nil, fmt.Errorf("Error assigning %s: %w", error().LHS, err) // LHS=left hand side, i.e the variable name

Alternately:

try armConfig, @err := builder.Build() ? goto err
try oauthConfig, @err := armConfig.BuildOAuthConfig(env.ActiveDirectoryEndpoint) ? goto err
try hamiltonEnv, @err  := environments.EnvironmentFromString(config.Environment) ? goto err
err:
  return nil, fmt.Errorf("Error assigning %s: %w", error().LHS, err) 

---

Using goto err is how I have handled errors for years — I have found numerous benefits to using the pattern — and I really do not want to see the ability to do so get nerfed by Ian's proposal as originally written.

[mukunda-]

@mikeschinkel I'm one of those programmers who has a mental block from using goto from all the stigma behind it. However, I think you bring up an excellent point about it and central error handling. I see the main goal as error decoration, where the message captures details of the error source.

One thing to note is that you can still take a similar approach with the current proposal using defer. For example:

func WriteTheText() (rerr error) {
   defer func() {
      if rerr != nil {
         // decorate error
         rerr = fmt.Errorf("failed writing text procedure: %w", rerr)
      }
   }()
   
   file := os.OpenFile("test.txt", os.O_RDWR, 0644) ?
   defer file.Close()

   file.WriteString("The Text\n") ?

   return nil
}

When you bring up goto, I see it as a primitive version of try-catch. That is, error decoration or handling happens in a designated area.

@ianlancetaylor I think the proposal could consider a special error-handling construct like try-catch. Where, rather than returning the error, it would forward it to the nearest catch. If there is no catch, then it returns it.

func WriteTheText() error {
   try {
      file := os.OpenFile("test.txt", os.O_RDWR, 0644) ?
      defer file.Close()

      file.WriteString("The Text\n") ?
   } catch(err) {
      return fmt.Errorf("failed inside of writing text procedure: %w", rerr)
   }

   return nil
}

Although I'd be wary that people from other languages might find try-catch confusing. In this case, it's not catching anything automatically. It's catching and decorating a return value.

[apparentlymart]

I think that I might have a different definition of "shadowed" than some others in this thread and so we're talking past each other a little.

When I said "shadowed" in my earlier comments I meant that a child lexical scope has a variable whose name matches a variable in one of its ancestor scopes.

When I said "reassigned" I meant that the same err variable was reused across multiple assignments to represent the errors from a series of separate calls.

The example I shared removed both the one example of shadowing and the various examples of reassigning. Although indeed that specific example was not wrapping all of the errors, even if it did there would be no shadowing or reassigning: each call would have its own local err in its handling block, with no err in the parent scope and thus no shadowing.

If you define these terms differently then I can understand reaching different conclusions from reading those examples. I'm not meaning to say that your concerns are not justified, just that I think we are discussing different concerns using the same words, and so we should probably shift to a different example that illustrates the form of the problem others were concerned about, rather than the form of the problem I was concerned about (which the proposal already largely addresses). I don't know if I understand exactly what the other participants are concerned about and so I'd invite them to share their own real examples where introducing this proposal to an existing real codebase causes more "shadowing" than was present before the proposal, by whatever meaning of "shadowing" they understand.

[ianlancetaylor]

Thumbs-up this thread if you think it's OK for the optional block to fall through to the code that follows.

Thumbs-down this thread if you think that it should be an error if the optional block does not end with explicit flow control, such as return, goto, panic, or fallthrough. For example, we could have the block panic if control flows through.

[mikeschinkel]

Explicit is better than implicit, especially for a reader who is only marginally skilled in the ways of Go.

IOW, if this proposal were to be accepted — which I have issues with it as is that I have and will state elsewhere — then I think such a scope should be defined that it must have a statement that determines what it should after execution, and that should include continue — as @apparentlymart pointed out — and break.

[vispariana]

I strongly disagree with the second option.

1. We are in the language design phase and are discussing how the new optional block should behave from a language spec perspective. If we require the optional block to always return or panic, then this check in my opinion MUST be a compile-time check. If the current compiler is not able to detect if a block always panics, then I believe we should not even consider that option. Having a piece of code that may cause a runtime panic because the coder has not adhered to the specs of Go, is a deal breaker to me.

2. In my experience, while the majority of errors are dealt with by returns, the cases where an error is a soft error and is just handled by logging, joining the error with some other error, etc. are not rare too. gin-gonic/gin handlers, for example, do not return errors so their errors have to be handled differently. Also this would make the new syntax unusable in codes like this which are not uncommon:

   var bigErr error
   for _, item := range items {
       handleItem(item) ? err {
           log(err)
           bigErr = errors.Join(bigErr, err)
       }
   }

   or

   for _, item := range items {
       validate(item) ? err {
           continue
       }
      handleItem(item)
   }

   of course these can be written in the old way (if err := fn(); err != nil {), but if we are finally discussing changing the error handling in go after years, I'm hoping for a change that does not force me to use the old form from time to time because there is something that can't be done with the new ? syntax.

[AndrewHarrisSPU]

Strongly agree with @vispariana on this. Trying to digest the proposal, I definitely think dialing back the impact of ? is a healthy inclination, but the more I look at the qmod output and try to improve upon it, I wonder about an opposite inclination, dialing it up to the point that var err error and if err != nil vanish.

Roughly, the cases where more elaborations are required are the ones where error handling goes beyond the kind of control flow or wrapping that Option<T> tends to handle simply. I'm starting to believe that in these cases there is a value proposition for the proposed ? aside from token reduction that's more subtle around scoping and composition of control flow. Demanding control flow in the block doesn't quite fit these cases.

[apparentlymart]

FWIW if I understood both the original idea and the given counterexample correctly, the first code snippet in @vispariana's comment would still be allowed but would need to be spelled like this, with an additional statement to make it explicit that falling through is desired:

var bigErr error
for _, item := range items {
    handleItem(item) ? err {
        log(err)
        bigErr = errors.Join(bigErr, err)
        fallthrough
    }
    // ("continue" would also be equivalent in is case, since there
    // are no other statements here after the block, but I'm assuming
    // this example was intended to represent a case where some
    // work ought to happen for every item even if "handleItem"
    // fails.)
}

I don't mean this comment as an argument against the feedback. I just wanted to make sure it was understood that the mention of fallthrough in the original question was with the specific intention of it allowing someone to deal with the less common case where execution must continue despite the error.

(The validity or not of the second example with continue was the subject of some discussion above already, and although it's not been answered definitively yet I've been assuming for the sake of voting here that continue would be one of the allowed "explicit control flow" statements.)

[AndrewHarrisSPU]

Forgetting fallthrough could be a hazard. Sampling 30 random files from qmod output and (sloppily) counting the applications of ?, I found the largest category by 3x or 4x was in _test code invoking t.Fatal/Err/Skip sorts of control flow. Just arguendo, in this situation forgetting fallthrough could lead to passing go test in an unfortunate way.

[JetSetIlly]

The conversion in this file doesn't seem right to me.

https://go-review.googlesource.com/c/go/+/644076/1/src/cmd/go/internal/imports/scan.go#31

		info, err := fsys.Stat(filepath.Join(path, name))
		if err != nil {
		    continue // Ignore broken symlinks.
		}

to

		info, err := fsys.Stat(filepath.Join(path, name))
		err ? {
		    continue // Ignore broken symlinks.
		}

[tmaxmax]

Having the variable on the other side of the question mark would also discourage code like:

x, err := foo()
err ? err {
    // handle
}

given that it stutters.

I think that what this operator brings to the table is not having the error variable in the main scope. This will also discourage some gymnastics which happen in more complicated functions around error handling. I really like this feature for honestly solely this reason.

[ianlancetaylor]

@ncruces A plain err is an expression statement because it is an expression that appears as a single statement. In the current language this is invalid, because it will get an error saying that the variable is not used. That is why the spec is written as it is. But adding the ? makes it a valid expression statement, because with the ? the value is used. I agree that if we adopted this approach, we would have to adjust the spec.

(If we go the route of requiring the variable to be declared after the ?, then the only way to use this with a block would be to write something like

    err ? err {
        return
    }

which I hope would never happen. I don't know whether it should be valid or not.)

[gazerro]

@ianlancetaylor in the following code:

    err ? err {
        return
    }

did you perhaps mean to write:

    err ? err {
        return err
    }

If we go the route of requiring the variable to be declared after the ?, then the only way to use this with a block would be to write something like [...]

(If we go down this path, I would make the variable optional. If no variable is specified, no new variable will be introduced, allowing us to write:

    err ? {
        return err
    }

where err inside the block refers to the already declared err variable.)

[jimmyfrasche]

err? on its own line is useful but the gain from using it on its own line with a block is negligible so even if it were err ? err { that's fine because you could just write if err != nil { instead

[adamshone]

info, err := fsys.Stat(filepath.Join(path, name))
err ? {
    continue // Ignore broken symlinks.
}

My reservation about this is that to someone unfamiliar with the operator it just looks like shorthand for a nil check. But it only works for type error, which seems unintuitive. If I can do the above, I'd wonder why can't I also do this:

info := myAPI.Search()
info ? {
    // Do something with the info
}
// Response was nil, return

[jherman4]

In my view disadvantages 1,2,4, and 6 make for a compelling case that we would be sacrificing a lot of code clarity here. Whereas one of the go proverbs I go back to frequently as a guiding light is:

Clear is better than clever

[DmitriyMV]

Disadvantage 4 mostly goes away if this is restricted.

[ncruces]

No it doesn't. The syntax is still ambiguous and dependent only on the presence of a new line to know what it means.
"It gets caught the first time it runs", is very different from "the meaning is clear at code review time."
Most whitespace issues in Python also get caught the first time it runs.

[qiulaidongfeng]

Is it possible for us to update the cover to achieve half test coverage for one line of code execution?

For example:
v := f()?

Only executed one of the cases where err is nil or not nil.

Display half covered of this line.

[ianlancetaylor]

I agree that if something like this proposal is adopted, it will be necessary to adapt the coverage reports accordingly.

[ncruces]

I actually use github.com/dave/courtney which takes a view that lines that only bubble up the error do not count for coverage.

For courtney only lines that generate a new error, or lines consume/handle the error matter.

I'm pretty happy with it, I think the decision makes sense

[prologic]

I'm not in favor of a language change like this as it hurts the readability of the code. As a vision impaired person, I would actually find it difficult to read code like this myself.

I would, however, be open to other forms of syntax that are more readable like using a keyword like else.

[JetSetIlly]

Yes. I worry about that too.

I think people like ? because it's a symbol not used anywhere else in the language. But the disadvantage is that it is difficult to read. I agree with you that a complete keyword rather than a symbol would be better.

However, I'm not sure else is a good fit. The proposal currently allows the following type of construct

err ? {
    return fmt.Errorf("example: %w", err)
}

Which would become

err else {
    return fmt.Errorf("example: %w", err)
}

Because else is used in a different way already I'm not sure if I like it.

I can't think of a better keyword but it would need to be unique in my opinion.

[prologic]

I agree, else is probably not the best choice here as it's used for conditional constructs. I admit I replied to this discussion during a quick bathroom break 🤣 -- Let me think about this... How about something like this?

someFunc() err {
  return fmt.Erorrf("something went wrong: %w", err)
}

The problem though is that we're not hiding a hidden local variable err somewhere in the local frame, which to me feels a bit too "magical"™ if you ask me. The explicit if foo, err := someFunc(); err != nil { ... } has always felt natural.

[DeanPDX]

How does the proposed ? syntax work in the event that some non-idiomatic code returns an error that is not the last return value? What happens with something like this?

// Because returning errors last is a convention, not part of the language...
func notIdiomatic() (error, string) {
	return errors.New("yikes"), ""
}

I'm assuming you have to return an error as the final value to opt in to this?

[ianlancetaylor]

Correct. The ? is only permitted after a statement within a function whose last result parameter implements error.

[prologic]

This further makes the language's semantics a bit awkward (aside from the readability issue I raised realier). Now you have to add to your cognitive load "is this function the right signature for ?? hmm"

[ugorji]

This further makes the language's semantics a bit awkward (aside from the readability issue I raised realier). Now you have to add to your cognitive load "is this function the right signature for ?? hmm"

I think, via convention, we've already got "trained" to have error as the last parameter. I don't forsee any extra cognitive load here in practice, not even a little bit

[shivam-116]

Arguably, via convention, we've already got "trained" to read and write "if err != nil", yet it is labelled as introducing cognitive load when reading/writing code. If we are to rely on developers already being used to certain idioms to the point of it essentially becoming muscle memory, why can't we apply that here?

[jherman4]

A distinction that looms large for me is that if err != nil does not require err to be the last return from a function. This

if v, err := someFunc; err != nil {
   ...
}

is exactly as clear as:

if err, v  := someFunc; err != nil {
   ...
}

Although the former is idiomatic whereas the latter is not. Personally, I would rather leave idioms as strong conventions than to start enforcing them with language features, even if those features are essentially optional.

[jfgiorgi]

I'm new to this discussion so sorry if already discussed but

Why not generalize ? to be an operator usable everywhere and not specific to Error ?

A ? var { optionnal block }

means remove last value from A and store it in a new variable var. If that value is "zero/null" for its type (nil for interface) call the optionnal block (var is only valid in that block)
The whole expression returns the values of A without the last one.
if the block if omited it default to { return var }

[jfgiorgi]

I've seen it before posting and I don't agree with

Supporting other types confuses that focus

I understand the focus and intent (reducing boilerplate) but introducing a new syntax specific to the error type seems to break what is nice with Go (errors are just values like any other values). It doesn't feel 'Go'.

A type agnostic "remove last value and test it" operator feels more 'Go' and can be used for more than error handling.

[tmaxmax]

It's difficult to generalize the implicit return: a simple return var works only when the return type of the function is that var's type. Around errors there is the convention to return it as the last value; around other types there is no convention. You can't just arbitrarily choose that the implicit form will return the value as the last value.

Moreover in some cases you wouldn't want to ignore the empty value, or the "error" value is neither zero, nor any other value. For example, you might have sentinel errors defined as struct{}, or array indexes where -1 is the error value. What the useful "zero" is depends on type and context, and doesn't seem generalizable.

Regardless, if this were to be generalized it would need explicit variable declaration, an obligatory block and I would argue that also implicit fallthrough. When generalizing to every type many assumptions are not true anymore.

[apparentlymart]

Based on this thread I'm imagining a hypothetical expansion of the proposal where the naked ? only works for a trailing error but the form with a block is more general and can take an arbitrary number of symbols such that the number of items before := and the number of items after ? must add up to the number of results from the expression.

For example:

result1 := Something() ? result2, result3 {
    // result2 and result3 are only in scope in here,
    // and have the second and third results from Something(),
    // regardless of their types.
}
// result1 has the first result of Something()

(I'm sorry if this mischaracterizes the intention of the idea of this thread. If I appear to be arguing with a strawman here then that wasn't my intention and please disregard the comment.)

However, it seems like that generalization would require some weakening of the behavior, such as:

• The current proposal's rule for whether to enter the block is error-specific, whereas this seems to require something that would be applicable to a value of any type. Two options come to mind:

  1. Just always enter the block, and let the content of the block decide whether to diverge or fall through to the following code. In this case, the benefit of the feature is really just in isolating a subset of the results into a nested scope.

     result1 := Something() ? err {
         if err != nil { // The need to still include this doesn't seem very satisfying
             return err
         }
     }

  2. Test whether all of the values are non-equal to the zero values of their type. While this would work, I can't really think of any sensible justification for it because the zero value of a type does not necessarily represent "okay". (In fact, for bool the opposite is typcially true in the result, ok idiom.)

• That treatment seems like it would foreclose on the question from discussion: spec: reduce error handling boilerplate using ? #71460 (comment), because if it's no longer error-specific then the justification for forcing a control flow change is no longer as clear, and it wouldn't make sense at all if the answer to the previous point were option 1 where falling through is how we represent "no problem".

• The rule for a shorthand return inside the optional block, where all but the final error value are forced to be zero-valued, is not so obviously defensible without the focus on error handling: the convention that other return values are irrelevant unless documented otherwise when an error is returned does not generalize to return values of other types.

With all of that said then, I think the focus on error values in particular results in a set of rules that are more clearly defensible by reference to existing Go idiom, whereas generalizing it further might (and has, in some earlier similar proposals) lead to the rules feeling considerably more arbitrary and thus harder to learn and remember.

(I'm writing this with some caution since this seems to be on the boundary of disrespecting Ian's request not to discuss alternative proposals here. I've tried to take care to frame this as a more general variant of the same proposal rather than something entirely new, but let's be mindful as we discuss further that we ought to try to stay relatively close to what Ian proposed in order to keep the discussion on track.)

[ianlancetaylor]

A type agnostic "remove last value and test it" operator feels more 'Go' and can be used for more than error handling.

But test it how? I hope it is clear that we want to execute the ? block if a value of type error is not nil. How should we generalize that to other types? The most obvious rule is that we execute the ? block if the variable does not equal the zero value of its type. That would mean that for a bool we would execute the ? block if the bool is true. But for something like a type assertion or a map lookup, that would mean that we would execute the ? block if the expression in some sense succeeded, whereas for an error value we would execute the ? block if the expression in some sense failed. The potential for confusion seems fairly high. And that confusion is arising because we are trying to extend a construct designed for errors to work with other types, but errors aren't the same as other types.

[apparentlymart]

I must admit that this root idea of having a general solution for "scope splitting" and forced control flow, without the error focus, piqued my interest just from the perspective of liking features that are orthogonal and relatively unopinonated. Once I got this bug in my head I couldn't resist playing with the idea further to see where it might lead. The following is not actually a proposal... I think of it more just as a design exercise, but I'm sharing it in case it contains something that someone else might like to build on. (Perhaps this is also an example of the "share one thing that everyone can disagree with" thing? 🤷‍♂️)

I essentially just started with the questions I raised in my previous comment: various parts of the current proposal rely on established idiom for error values in particular, which I took to mean that a more general form of this would need to make the decisions explicit on the page rather than implied in the language itself.

I see two main interesting parts to the original proposal that I'd want to preserve even if it were not error-specific:

1. It splits an assignment operation from a multi-resulted expression into two parts, with some variables "assigning leftward" into the current scope representing the happy path, and some other variables "assigning rightward" into a local scope dealing with an exceptional path.
2. Although this is not yet part of the current proposal text, it also permits introducing a rule that the exceptional path must end with an explicit control flow change, which reinforces that the indented block is the exceptional path (as opposed to the happy path) and allows a reader of the code to assume that the exceptional path prevents continued execution unless there's an explicit fallthrough at the end of the block.

Once I thought about "assigning leftward" and "assigning rightward" I invented an (admittedly-rather-odd-looking) "declare-and-assign rightward" symbol, =:. It's followed by an expression list just like the one that appears before a := in today's language. That expression list is then followed by the if keyword and then a boolean expression which decides (probably based on the rightward-assigned symbols) whether to enter a block that appears immediately after that expression.

result := SomethingThatMightFail() =: err if err != nil {
    return nil, nil, fmt.Errorf("something failed: %w", err)
}

thing := someMap[foo] =: ok if !ok {
    continue
}

Unless the exceptional block ends with a fallthrough statement, it's a compile-time error if the compiler cannot prove that the end of the block is unreachable. Aside from that additional constraint, statements in the block are interpreted just as they would be inside a separated if err != nil block as we'd write in today's Go. In particular, the current proposal's special treatment of shorthand-return in the exceptional block is not suitable here because that makes error-specific assumptions, and so any shorthand for return would need to be dealt with as an orthogonal proposal like #21182. (That particular proposal, if accepted, would allow the first example above return to be written as return ..., fmt.Errorf("something failed: %w", err).)

This variant of the idea does not include any equivalent of the naked ? which implicitly returns the error, because I could not find any reasonable way to generalize that rule to work across all possible result types. Perhaps the naked ? without a subsequent block is still defensible as an error-specific shorthand even if the longer form ceased to be error-specific

---

Again I want to reinforce that I am not actually proposing this! I was just interested to explore the hypothetical "what might it take to make this idea error-type-agnostic?".

In particular, the above is quite "stuttery" -- particularly in the ok if !ok case -- and doesn't do quite as much to reduce the reader's cognitive load because they will probably still want to inspect the branching predicate at the end to understand exactly what the exception condition is for a particular statement, and there is still some risk that someone might mistakenly write err == nil or ok and thus get the opposite control flow to what they intended.

For me, exploring this mostly just further convinced me that the error-specific nature of the current proposal is an advantage rather than a disadvantage, but of course others may differ in that opinion.

[lukemassa]

Is there a good way to think about "reading" the new syntax? I think it'd be easier to get used to it if I could substitute in a specific natural language phrase when I saw a question mark, so when I read it aloud I could follow the flow. Maybe "on error"? Not sure how that works with the ? at the end of the line.

I'm thinking specifically about trying to explain my code to someone newer to go, if they were to see this:

r := SomeFunction() ?

and ask "what does the ? mean?" it'd be nice to be able to say "read the ? as ..."

[JetSetIlly]

An alternative could be:

canFail() onerr {
    return
}
canFail() onerr return

It's not so much an alternative to ? that's required but a meaning in a human-language that can be used in the teaching and thinking process.

People think in different ways but speaking personally, I don't think in symbols, I think in human-language. For instance, when reading a sigma symbol in a math equation, I think "sum of". I don't think "Σ".

In a teaching scenario describing the use of ? in terms err != nil is meaningless because the student may not have been exposed to the old way of doing things. It would be be poor teaching to say, "we use '?' instead of having to type 'if err != nil'".

We need a way of describing what ? is doing without referring to the thing that's being replaced.

I think error handler is a good way of thinking and talking about it but I'm not 100% sure yet.

[apparentlymart]

While I would agree that explaining it as a direct translation of if err != nil would be unwise, for the reasons stated, I do already tend to "pronounce" if err != nil as "if there is an error", and so FWIW that's how I've been mentally "pronouncing" the ? symbol as I read and write examples in this proposal too.

Of course, for the form without an optional block something also needs to represent the behavior being implied by its absence. I must admit I hadn't thought too hard about that before this thread because I found the design details of the block form more interesting/relevant to me, but my first instinct is to pronounce it as "return if there is an error".

I will pre-concede that these particular interpretations don't speak to exactly what it means for there to "be an error", so for someone very early in their Go journey some more exposition would still be required. I expect I'd preface it with "this function uses its last result to indicate whether there's an error", before then discussing how the ? symbol interacts with that.

(Mostly just thinking aloud here. Sorry if this was too waffly and un-useful.)

[doggedOwl]

i would read it as "onError: return error" short form.
long form the whole statement become "var = something OR return fail reason"

[ianlancetaylor]

Personally I read a plain ? as "or return". I read a ? followed by a block as "on error".

[tmccombs]

I think if there is a block you could read it as "or", for example "call someFunction or return fmt dot Errorf...". Or maybe "handling error with"

And in the block-less case "or return error", or "propagating error"

[kh3rld]

Hey @ianlancetaylor, I think this proposal is a really interesting step towards simplifying error handling in Go.

One thing I was wondering about is how the implicit err variable will play out in larger codebases where variable shadowing is already a common pattern. In cases where err is already used elsewhere in a function or loop, could this lead to confusion or unintentional bugs? It seems like it might be a little tricky to ensure that the err within the ? block doesn’t accidentally overshadow other variables, especially in larger or more complex functions.

That said, I do think the potential to streamline error handling without interrupting code flow is appealing. The fewer lines of boilerplate, the better, especially for readability. I’d love to see how this might play out!!!

[flibustenet]

I believe it's too magical, we should keep it explicit and prohibit the use of canfail() ? alone witch can be abused and go under the radar.
It should be mandatory to write at least the return:

canfail() ? {
    return err // don't forget to annotate !
}

It looks more like Go code that we use to read and keep the encouragement to add an annotation.
It could be a first proposal more simple and let us add implicit return (which should be exceptional, right?) later.
I would like to see this on the stdlib if it's possible, to compare.

[shivam-116]

nothing is stopping a developer from simply ignoring the error. So if someone doesn't want to deal with it, they just skip the error checking outright. Having some construct to make it slightly more convenient to handle errors I think this will happen a lot less.

@roccoriu-six Not sure I get your point. The error can still be ignored with or without the proposed syntax, and the topic of ignoring the error is rightly out of scope for this discussion. The point here is this proposed syntax makes it easier, or even encourages, thoughtless propagation of errors, where one might have otherwise stopped to consider if they should annotate/decorate.

[apparentlymart]

I don't wish to focus overly tightly on one example, but I would argue that it's a matter of context whether it's valuable to distinguish between the three separate steps of this unexported function that's therefore presumably already an implementation detail of something else.

In the specific codebase I took that example from, that extra level of detail is entirely unnecessary for the way that error is used in practice, and because it's an unexported function it cannot possibly be used in any other way.

I've seen too many Go programs generating user-facing errors with confusing nonsense like "failed to save thing: saving thing: saving the thing: flushing thing: writing trailers: write: broken pipe", where at least some of the prefixes are redundant because someone felt compelled to add a prefix at every step even though some of the steps are just implementation details caused by e.g. refactoring the code to reduce cyclomatic complexity, or a particular detail just literally being irrelevant at the level of abstraction where the error is finally reported.

While I'm certainly not meaning to argue that it's always okay to skip annotating errors -- and I don't disagree that some folks go to the extreme where the resulting error is so lacking in context to be utterly useless, like io.EOF bubbling all the way up without any wrapping -- it's also not true that it's necessary always better to add annotations at every stack frame. (Whether that means it's justified to have a special syntax for returning unannotated errors is still a valid question, of course! I think I've made my opinion on that clear but I respect that others differ.)

[jba]

I agree with @apparentlymart: choose your annotations carefully. In this particular case, there is very little that can go wrong inside gzip with the given arguments (notably, using a bytes.Buffer, which cannot fail). If something does go wrong, it would be most useful to know the origin of the data, which this compress function cannot help with. So in my opinion these errors should not be annotated.

[mikeschinkel]

@apparentlymart — If I were to see this code I would be seeing what I consider to be a code smell. If that code was written by developers on a team I lead I would ask them to annotate each of those errors because know if it were the write, the flush or the close that triggered the error would make a world of difference in remediation.

func compress(data []byte) ([]byte, error) {
    b := new(bytes.Buffer)
    gz := gzip.NewWriter(b)
    gz.Write(data) ?
    gz.Flush() ?
    gz.Close() ?
    return b.Bytes(), nil
}

That lack of error annotation would be especially bad if compress() was in a package I was using and my code needed to know if there was an error in write, flush, or close in order to take different actions.

Features that encourage such inanity are anametha to writing robust code IMO.

---

However, what if rather than bikeshedding over compress syntax we consider why that code is a code smell and discuss how we might be able to envision an improvement? The issues include — but are not limited to — lack of annotation:

• What if when a line of code like func(params) ? generated an error that Go would then generate ErrorInfo object — also a error and join it with the original error and assign it to err or a named error object?
• And what if ErrorInfo.Cause() would return the string "gz.Write(data)"?
• And what if ErrorInfo.Vars() would return a []runtime.Var containing the list of points to the package variables and locals variables in current scope (which would include parameters)?
• And what if ErrorInfo.Scope() would return a runtime.Scope with the filepath, line number, package name, type name when applicable, method or func name, and some form of description of block scope?

All of these things could be easily compiled in by Go but take a large amount of work and code for the developer to do themselves. If Go did this it would go a long way to handling objections to not annotating errors.

[apparentlymart]

@mikeschinkel I think the idea in the second part of your comment seems similar to the discussion in #71460 (comment). Perhaps you'd like to share it there too just to keep the discussion related to potential automatic/implicit transformations of the error value together in one thread.

[Hypnotriod]

I would prefer more explicit and more versatile though:

r, err := SomeFunction() ? err != nil {
    return fmt.Errorf("something failed: %w", err)
}

r, ok := SomeFunction() ? !ok {
    return errors.New("I'm not ok when it is not ok")
}

[goodevilgenius]

That's almost exactly like:

if r, err := SomeFunction(); err != nil {
    return fmt.Errorf("something failed: %w", err)
}

The main benefit is the change in scope, but I don't know that that's enough of a benefit to be worth the addition.

[Hypnotriod]

I would say it should be exactly like:

if err := foo(); err != nil {
    ...
}

[Hypnotriod]

The main benefit is the change in scope, but I don't know that that's enough of a benefit to be worth the addition.

I agree.

[davidmdm]

Although I am still strongly opposed to the optional block (meaning that I believe the block should be required and explicit even in the simple return err case) if the block-less form makes it in the proposal, then I think it needs an accompanying change to go vet.

The issue is that error handling is now going to be easy to omit by accident both by the writer of the code, and by the reviewer who reads the code as it is a single character.

// oops I forgot to handle the error
Foo()

// Handled!
Foo() ?

I believe that functions that return errors (at least as their last argument) must be explicitly vetted to either use the ? operator or have an assignment (blank or not):

// Fails Vet
Foo()

// Passes Vet
_ = Foo()
err := Foo()
err = Foo()
Foo() ?

This is a useful vet check today, but the problem is exacerbated if error handling is one trailing character that might be hidden off screen.

[thepudds]

See for example #20803, #19727, #20148, #71432.

[davidmdm]

Thanks for adding the existing proposals.

What I am trying to say is that it would not be responsible to accept this proposal without this new check.

The problem already exists today, but would be worse if this proposal was accepted and implemented as is.

[deefdragon]

I don't think a vet check is a good idea here. there are a number of cases I've encountered where errors returned from certain functions are not worth handling.

specifically, I have several requests that, if they fail, need to do a best-effort close of resources. if the failure was due to those resources being unavailable, the close will error as well.

I already know the resource is unavailable from the failure error, so it's not worth mudding my logs or handling the error on the close in any way. thus it's a best effort call.

having a vet check means I NEED to deal with that error somehow, even tho there is nothing to do with it.

[davidmdm]

@deefdragon

The blank assignment explicitly lets the reader know that you wish to not handle the error:

_ = Foo()

And that would satisfy the vet.

With this proposal it is incredibly easy to forget to handle an error. Either by mistyping, a bad edit, merge-conflict etc.

I am sure that if this vet check was implemented it would surface a lot of locations of errors that were forgotten.
It may be annoying in some cases but would lead to more better guarantees around code quality.

[myitcv]

Very much a drive-by comment. I've quickly scanned the responses thus far for the term "scope" and I don't think this point is covered. So here goes.

I propose permitting statements of the form

	r, err := SomeFunction()
	if err != nil {
		return fmt.Errorf("something failed: %v", err)
	}

to be written as

	r := SomeFunction() ? {
		return fmt.Errorf("something failed: %v", err)
	}

Is r is scoped by the outer block, or the error handling block? I'm assuming the outer block, given the original code.

In which case my brain is struggling, because it seems the above as being very similar to:

for r := 0; r < 5; r++ {
   // r only in scope in this block
}

or

if r, err := SomeFunction(); err != nil {
   // r only in scope in this block
}

Maybe it's only me, but it doesn't seem visually consistent with similar constructs.

[gregwebs]

err is limited in scope to the brackets but r is outside that scope.

[DmitriyMV]

There is difference because for both your examples (if and for) signals the creation of the inner scope. Where ? is a postfix, so it creates a new scope for the err but uses outer scope for the r.

[mikeschinkel]

@gregwebs — Yeah, well that is really inconsistent. 😧

[Ja7ad]

This is a discussion about a new syntax that may be used to handle errors. This is issue #71203 converted into a discussion.

I've written a tool that converts ordinary Go code into code that uses the syntax from the proposal at #71203. That tool is available at https://go.dev/cl/643996. In order to build and use it you must first apply the changes in the patch series ending at https://go.dev/cl/642502.

Someone who chooses the Go programming language does so purely for its philosophy of simplicity and efficiency. Otherwise, other languages remain a question mark, and the project or service intended to be written in Go would have been written in those languages instead.

Do not sacrifice the language’s simplicity and philosophy for the sake of reducing token usage.

[glycerine]

I find the '?' proposal a little too magical, and I'm
concerned about being able to set the
values of other return values when the magic happens.

Less space devoted to error handling could be
achieved simply by being able to express
a conditional return in a single line; reducing
the vertical space devoted to error handling
from 3 lines to 1 line each time.

Thus I would rather see a "return when" form:

 // ideal syntax (not currently available):
func example() (p *int, s string, err0 error) {
   ...
   err := someOperation()
   return (nil, "when-I-need-a-specific-string", err0) when err != nil 

We could even have a short form of the "return () when" form like

return when err != nil

that is equivalent to today's ubiqitous

if err != nil {
   return
}

[mukunda-]

Returning something specific on an error is much, much less common than just breaking early and using default values for the returns. If you need something specific, then you should not use the convenient syntax and just do it the old way.

[Maqi-x]

In my opinion, this change is unnecessary - error handling in Go is both the worst and the best part of the language, but there is no point in changing it.

much more useful would be the operator ? if it would simply remove the value of error from the end of the expression if it is there It would help if some function returns xyz and error, but you are sure that error will be nil, then if you want to give a call to this function directly in a call to another function, etc. then you can not because it continues to return 2 values, and so you can, for example:

r := bufio.NewReader(os.Stdin)
name := strings.TrimSpace(r.ReadString('\n')?)

is this readable? It's not for me to judge, well, but in any case it simplifies the code, because without it you would need an additional variable or anonymous function, and in such cases sometimes error handling is unnecessary

[vispariana]

Go is not a scripting language. Enabling one-liners will remove one of the key points in Go: writing safe and predictable codes.

[donatj]

I genuinely do not see the advantage. It's only couple characters extra to not do this. Not doing this avoids treating errors as something special/magical other than a value.

If the extra line is what bugs you, you can, today simply start doing:

r, err := SomeFunction(); if err != nil {
    return fmt.Errorf("something failed: %v", err)
}

[chad-bekmezian-snap]

Only problem with this is that pretty much nobody writes it this way, adding to cognitive complexity when you see this. With the proposed solution, we would all get used to the new "standard" way of handling errors.

[mukunda-]

go fmt will put the if statement on the next line. Formatting the error is useful yes, but not if you are returning from a thousand different points in the code from errors that are basically very rare exceptions. The majority of error handling is returning the error directly.

[SoftExpert]

You can write it like this, though, and go fmt will accept it ...

if r, err := SomeFunction(); err != nil {
    return fmt.Errorf("something failed: %v", err)
}

[emiago]

thanks for pointing this out. Seems like people forget about gofmt and got used to it.

@mukunda- It can be actually opposite in DEBUG situation as your reading then must be more carefull. Specially as this proposal even hides return value.
In some sense I could reflect reading just try/catch wrapped code with this syntax. Wording could improve but...
Also note our brain has power to skip reading when recognition is fast.

[donatj]

@SoftExpert I would have suggested that, but the problem is that r in that case is scoped to the if block

[mriart]

In my humble opinion, I don't see much less verbosity. On the other hand, fundamental design principles of go are broken, such as the return of two variables.

I find the third example interesting:
SomeFunction2() ?
when it returns err, without processing. If this is a frequent situation, I would make another proposal to maintain the foundations of go.

If _ means "ignore", ? could mean "return the variable if it is different from nil". Then:
r, ? := SomeFunction()
would return the second variable as is. It would be necessary to have some checks at compile time (i.e. it is of type error). This is a simple syntax that would save verbosity in many common situations.

[SteveRuble]

@ianlancetaylor, OK, so it's been proposed before, but not in the context of a small tweak to a proposal that you think is worth considering. You don't owe anyone an explanation here, but I'm very curious about why you think that eliding the err variable entirely (and introducing implicitly defined (possibly shadowing) variables to Go) is better than having a succinct symbol for the value we're trying to wrangle here (especially given that your proposal already introduces a new ? symbol so it must not be intrinsically a bad idea to use a new symbol).

To be clear, I like your proposal a lot, but I also think that some of the concerns repeatedly raised in comments are compelling. This relocation of the ? addresses those concerns without significantly changing the proposed functionality. It's still narrowly targeted at error handling (not wide-ranging return on zero value tricks as in the linked proposal).

[ianlancetaylor]

I don't think that changing

    r := SomeFunction() ?

to

    r, ? := SomeFunction()

is a small tweak.

1. One of the goals of the proposal being discussed is to make it easy for the person reading the code to read the normal, non-error, path. That is why the error handling is moved to the end of the statement. Keeping the ? at the start doesn't support that.
2. One of the goals of the proposal being discussed is to provide good support for annotating the error, or calling functions like panic or t.Fatal, or otherwise doing something other than returning the unannotated error. While it's true that the proposal has better support for simply returning the error, it also improves the handling of taking a different action. And, it moves all of those actions off the non-error path, meaning that it can be applied consistently to a fair amount of Go code. Putting the ? on the right doesn't support that.
3. The ? at the end of a statement works similarly to the Rust language. Having an assignment to a special symbol cause the flow of control to change is unlike any language I know. Assignment and control flow are different kinds of operations that deserve different syntax. In particular, I question whether somebody unfamiliar with Go would understand what the assignment to ? means. Whereas, @fflewddur actually tested the syntax in this proposal with users unfamiliar with Go, and found that most could understand it (see disadvantage 1 in the original proposal).

I hope that helps explain my perspective on this approach.

[SteveRuble]

That helps a lot, thank you for taking the time.

Having an assignment to a special symbol cause the flow of control to change is unlike any language I know. Assignment and control flow are different kinds of operations that deserve different syntax. In particular, I question whether somebody unfamiliar with Go would understand what the assignment to ? means.

That seems pretty compelling. I can understand why someone else wouldn't share my intuitions here and it is unusual. But I still think that eliding the err variable entirely from the left side and making it magically appear inside the block also breaks intuitions. I feel like there must be a better way.

[apparentlymart]

The concern about the local err variable being named automatically/implicitly is the subject of #71460 (comment), and so @SteveRuble you might wish to add either a 👎 or 😕 vote to that thread (depending on what your view is about those two options as described in Ian's comment there), and add to that discussion if you have something to say about the alternatives that hasn't already been mentioned.

[flibustenet]

? in the end could be fine but it's too late. It looks like Rust but not like we use to read Go code.

[ivankorobkov]

Please, stop trying to change Go's error handling.

Yes, it's a bit explicit. But it's so great that errors are just values.

[mukunda-]

What about it is great?

The proposal isn't changing error handling or the fact that they are values. It's syntactic sugar. You can easily do the same thing with an if err != nil check. Languages like JavaScript pioneered excellent syntax through evolution like this.

[roccoriu-six]

The problem is not that go uses values for errors, I also prefer values over exceptions. But the way errors are handled, particularly in the most common cases where having the exact same boilerplate just makes the code less legible.

[tandr]

@ivankorobkov The proposal does not prohibit classical style of error handling. So, if you prefer to continue to use it in a classical form - all the powers to you.

[mukunda-]

What about our future ternary operator? 😅 (No please, I want this much more than ternary).

Why is there a space before the "?" I vote no space from go fmt. Just like in proper English .

[DmitriyMV]

There is no ternary testing operation in Go.

[mukunda-]

Also, speaking of formatting. Funnily enough, I think a lot of gogrammers would be less annoyed with the current state of errors if go fmt didn't turn this one line into three lines:

if err != nil { return err }

[bwplotka]

I actually like @mukunda- proposal, not sure why downvoted. If you use IntelliJ/Goland it actually does that by default:

[thepudds]

if go fmt didn't turn this one line into three lines: if err != nil { return err }

Hi @mukunda-, see for example #57645, #38151, #33113, #32437 (comment), #27135, https://swtch.com/try.html#gofmt1, etc.

My understanding is Ian has requested that this discussion here focus on this particular proposal, and that other ideas can be discussed elsewhere.

[mukunda-]

Sorry, just an aside there - the main feedback would be the dislike for the space before the question mark.

[mikeschinkel]

@ianlancetaylor — While there are glimmers of a better future in this proposal, there are numerous issues I see with it.

I have commented elsewhere on the things but I want to address my personal #1 concern; the fact that it would bake early return into Go as the easy path when early return is not how I want to handle errors. So let me propose a group of features to augment the proposal, in order of most important to me:

1. Allow goto label in addition to 1. naked and 2. block versions of ?. The ability to use goto with any new approach implemented for error handling is the # 1 thing I want from Go.

2. Add a block feature to labels such as you see here that only executes when a goto is called to trigger the label.

3. Use @ or some other syntax to means assign the variable like with = but only declare it if it has not already been declared. This would help with err for the error handling use-case but giving us a way to avoid shadowing the variable, but it would also be nice for refactoring too as it would mean we would be able to move lines of code around without having to constantly change from := to = and/or having to declare the variable with a var statement.

func doSomething() (int,error) {
   a, @err := doSomethingA() ? goto err
   b, @err := doSomethingB() ? goto err
   c, @err := doSomethingC() ? goto err
   value := handleIt(a,b,c)
err: {
      err = fmt.Error("Something failed; %w",err)
   }
   return value,err 
}

If your proposal gets accepted, please please consider giving us the flexibility to handle errors with more than just an early return. Adding goto support, adding label blocks, and adding a syntax for "assign but only declare if not declared" would ensure that we are not boxed having early return be the only low-effort approach to error handling.

[ijxy]

I like explicit handling by default and would argue that Go "feels" simple because of how little implicit "magic" there is the language.

That said, with this specific proposal I am concerned by:

1. Significant whitespace smells like bad design (ie implicit, ambiguous)
2. Implicit variables make code more difficult to reason about
3. Baking the value, err := convention into the language

(1) could be avoided (I think) by making the block non-optional. Either an empty block {} or perhaps nil could work?
(2) could be avoided, as others have suggested, by requiring a variable declaration for the error value.

Combined, you might end up with something like:

v := SomeFunction() ? nil // or {}

v := SomeFunction() ? myErrVar {
  return DoSomethingWithError(myErrVar);
}

(3) can't really be avoided if insisting on this shorthand ? syntax. I think the closest you could get is something where the declared variable has to shadow a variable in the original assignment, like

// does not follow val, err convention
myErrVar, a, b, c := SomeFunction() ? myErrVar { // declared error variable has to shadow a declaration on the LHS
  return DoSomethingWithError(myErrVar);
}

[tandr]

And since we now have "ignore" var _ (underscore), I think your example with explicit ignore of might be written as

v := SomeFunction() ? _ { 
    // block with some processing that does not need to have error value
} 

[Robert-M-Muench]

Being explicit is more effort once, but benefits hundreds down the road reading foreign code.

Removing the repeating elements of error handling to get a more compact code structure, with less noise, while staying explicit, is a good idea. However, I don't like the ? and wonder, if it's necessary at all:

value, err := doSomething() // no error handling here
value, err := doSomething() {} // return err, or panic, or ...
value, err := doSomething() {return errors.Join(err, fmt.Errorf("doSomething failed"))} // handle error

• Keeps value and err on the same side
• Explicitly mentions the error variable like today
• Keeps today's idea of explicit error handling
• Easy to spot and read