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.

[mikeschinkel]

@ianlancetaylor — This is a quick aside to ask a question.

"I don't want to discuss other syntaxes in this issue because that would immediately overwhelm the discussion of this particular proposal. There are many other places to discuss error handling syntax in general, it doesn't have to be here."

I totally empathize with the concern that trying to get targeted feedback while also allowing discussions of alternatives quickly becomes overwhelming and makes interacting with us an Herculean task. I would not want to be in your position on such a contentious topic.

OTOH I also recognize that human nature results in most people rationalizing their own specific input as being acceptable and so discuss alternative syntaxes anyway. That results in you and I guess everyone else being overwhelmed even though you tried to avoid it (and I do acknowledge that I am as guilty as anyone of said rationalizing on this particular Github issue.)

I think a key reason for this conundrum is that the current process does not manage both the desired feedback and human nature effectively. But given my interest in this specific issue I tried to imagine how the process could be improved.

I think I have identified a relatively simple set of ground rules the Go team could implement for discussion on future issues that could potentially help keep discussion to a manageable level by leveraging rather than fighting human nature. I'd be happy to write up a proposal or start a discussion explaining it if the Go team is open to considering it in earnest.

OTOH, if the Go team would rather not consider such a thing at this time then I would rather not invest the time and effort for something that would have effectively no chance to be considered.

So:

1. Are you/the Go team interested in considering a set of ground rules for discussion on future issues (Yes or No), and
2. If yes, should the idea be raised as an Issue, or as a Discussion?

[ianlancetaylor]

My experience is that a good number of people will simply ignore any requests, as can be seen on this very discussion, for the reasons that you mention. If you think you can solve the problem with, and this is extremely important, no extra work by anybody on the Go team, then sure, I'd like to hear it. It doesn't sound like an issue or a proposal, though, it sounds more like something to discuss on golang-nuts.

Note that this is not a general problem with Go's use of the GitHub issue tracker; it's a problem specific to the discussion of complex proposals. Perhaps surprisingly, we have only 60-odd issues with more than 100 comments, and many of those issues are actually repeated watchflakes reports.

[seankhliao]

Note that many people do not even fully read the proposals before commenting, any ground rules you try to set will be ignored (as we've seen in this and other proposals).

[mikeschinkel]

@ianlancetaylor — 
Thank you for responding.

I acknowledge almost all you wrote as true, especially the part about complex proposals — although I think you mean "contentious" more than you mean "complex"?

Some of the most complex proposals get very little comment from the community. OTOH, things that can easily be bikeshed — such as syntax — are much more apt to become contentious.

I will go ahead and prepare a proposal or discussion since you did not mention a preference, and I in my experience a mailing list is not the right place to present such a proposal. I will wait until I see what is required to submit a non-language change proposal before deciding proposal vs. discussion.

@seankhliao — 

"Note that many people do not even fully read the proposals before commenting, any ground rules you try to set will be ignored"

Absolutely true, I concur.

However, what I envision — if reinforced on every proposal and by most in the community — could become a community norm that would not require people to actually to have read that aspect of a proposal for them to be (made) aware of them.

So please consider the proposal after I have written it up and submitted it to decide if it might help or not.

[mikeschinkel]

@ianlancetaylor @seankhliao — Here is that proposal, as promised: #71741

[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.

[mikeschinkel]

The point of func(error) error is to provide a way to name the error value. Permitting func(error) error along with other possibilities doesn't address how to name the error value for those other possibilities.

I am not sure if you have seen the suggestion others have made elsewhere — though I expect you have — but a suggestion that really resonates with me is to couple the naked error handler with a required named error return value for the final return value. That seems to elegantly address the concern.

The following example is just showing the different potential approaches to error handling; please do not consider it as a good example for writing code taken as a whole;:

func getWidget(id string) (w Widget, myErr error) {

   // If this fails, if just jumps to the return statement
   dbConn := widgets.OpenDB() ? goto end

   // If this fails, if wraps the error with an annotation then 
   // jumps to the return statement.
   dbConn.ScanWidget(id,&w) ? {
     myErr = fmt.Errorf("cannot get widget; %w",myErr)
     goto end
   }
   w.loaded = true

   // If this fails, if just logs the error and continues on
   dbConn.WriteLastAccessed() ? {
     slog.Warn("Failed to write last access time","error",myErr)
   }

   // If this fails, if logs the error and immediately returns 
   dbConn.Close() ? func() error{
     slog.Warn("Could not close DB connection","error",myErr)
     return myErr
   }
end:
   // Here errorutil.Annotate() returns nil if myErr is nil, 
   // otherwise it wraps the error with the message
   return w,errorutil.Annotatef(myErr,"failed in getWidget(%s)",id)
}

[ianlancetaylor]

I don't understand what this construct means:

   dbConn.ScanWidget(id,&w) ? func() error{
     myErr = fmt.Errorf("cannot get widget; %w",myErr)
     goto end
   }

Go doesn't permit doing a goto out of a function literal into the enclosing function.

I'm also concerned about

func F() (err error) {
    if debugFlag {
        f1, err := os.Open("x")
        if err == nil {
            f2 := os.Open("y") ? {
                log.Fatal(err) // which err is this? what value does it hold at this point?
            }
        }
    }
}

[mikeschinkel]

@ianlancetaylor

"I don't understand what this construct means:"

Sorry, that is an unintended foible. I restructured that example a dozen times hoping to create an example that was somewhat reasonable showing different approaches, and I failed to make that case workable. I will edit my example.

"I'm also concerned about..."

I assume you meant to use a ? on the f2 := os.Open("y") { line?

Anyway, I would advocate that when ? is used Go would not let a developer shadow error variables. That would fix the footgun that shadowing has been, in a backward compatible manner. Thus the code would need to be written like this which would mean no ambiguity:

func F() (err error) {
    if debugFlag {
        var f1 *os.File
        f1, err = os.Open("x")
        if err == nil {
            f2 := os.Open("y") ? {
                log.Fatal(err) // which err is this? what value does it hold at this point?
            }
        }
    }
}

Of course, if #71522 were reconsidered, it would be a bit more elegant and we could collapse:

var f1 *os.File
f1, err = os.Open("x")

Into just

f1 :=, err = os.Open("x")

[ianlancetaylor]

Sorry, I did omit the ?. Fixed now.

I do not think it would be a good idea for something like "using a ?" to affect the identifier shadowing behavior.

[mikeschinkel]

@ianlancetaylor — Well, elsewhere someone pointed out that this approach would not work it they only wanted to panic, so I retract this suggestion anyway.

[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]

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.

[aslatter]

I voted 👎 as being against the optional-block, but I would be okay with some solution that allowed fmt.Errorf annotation as a one-liner with the ?. I'm not sure what that would look like, however.

[wichert]

It feels to me like if you add an optional block, you are already adding enough code that you might as well write out the full if statement. Not allowing the block also opens up the ability to use ? in a chain.

[jdemeyer]

I voted 😕 for "the block should be required" and then disadvantages 4 and 7 are immediately solved

[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.

[ianlancetaylor]

Note that vet already knows reliably whether functions return or not. If we use vet I don't think we need heuristics based on the function name. But currently vet only flags code that is clearly incorrect, which is not the case for an error block that falls through.

[AndrewHarrisSPU]

@vispariana

I'm not sure about this but I don't think the vet check can detect if the t.Fatal() or a panic() is wrapped in another function

I know a printf analyzer detects wrappers, and I think this is similar. func checkPrintfFwd, I think the logic is just walking up callers. It's not perfect, but catches some stuff.

[tmccombs]

If only go had a never type, so that functions like t.Fatal could return that to indicate that they never return normally.

[apparentlymart]

For those interested in making the language itself aware of "no return" functions, there's some discussion about that in #69591 (already declined some time ago) and #71553 (under discussion, but probably heading towards being declined per current discussion/voting).

[AndrewHarrisSPU]

@ianlancetaylor

Note that vet already knows reliably whether functions return or not. If we use vet I don't think we need heuristics based on the function name. But currently vet only flags code that is clearly incorrect, which is not the case for an error block that falls through.

Thanks, that's a useful, simplifying assumption. Shallowly, the fallthrough cases seem relatively manageable to me in the context of syntax that doesn't currently exist, that people would opt into, and could opt out of where appropriate.

[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.
		}

[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 err // (edited line from original post)
    }

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

[ianlancetaylor]

@gazerro Thanks, you're right, I did mean return err. Will fix.

[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.

[vispariana]

It goes away if the err variable declaration is mandatory when using the optional block

[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.

[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.

[Splizard]

err := DoSomething(); err if return err

or just

err := DoSomething(); if err return err

make it work with bools too and require the control flow keyword

[urandom]

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

or might be more readable?

DoSomething() or err { ... }

[JetSetIlly]

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

or might be more readable?

Yes. Although I favour the err being a left-hand assignment, as it would be in today's Go.

result, err := DoSomething() or {
   return err
}

In this way, or is just a pure replacement of if err != nil

I would be happy with the following as a one liner.

result, err := DoSomething() or { return err }

But we all have different needs and opinions, so there's never going to be one correct answer.

I think the only firm conclusion that can be drawn from these endless discussions is that nobody will be completely happy. @ianlancetaylor needs to put his foot down somehow :-)

[grandstairs]

Related, I appreciate that this was called out explicitly:

Disadvantage 1: This is unlike existing languages, which may make it harder for novices to understand.

I prefer a language to be readable by someone that doesn't program in it. I would much rather someone complain about having to press TAB so their IDE auto-completes the if err check than find non-Go developers are unable to read the code.

[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?

[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.

[apparentlymart]

The general question of idiom vs. explicit language feature seems like the typical conflict over desire paths: some argue that the informal path should be left informal, others argue that a fence should be erected to encourage using existing planned routes instead, and others argue that planners should respond to the apparent consensus by paving where the desire path formed so that it gains the benefits of a planned path like improved accessibility, or lampposts to make the path safer to use after dark.

I personally tend to be on the "pave the path" side of things, but this is such a classic disagreement across many different aspects of human society that I'm not surprised to learn that others approach it differently. 😀 Perhaps we can keep the metaphor in mind though and consider that while a desire path is usable and accessible to some, a planned path is often (but certainly not always) attractive to and usable by more people. (Of course, a poorly-planned path not so much, so we do still need to make sure the details seem right.)

[jherman4]

The general question of idiom vs. explicit language feature seems like the typical conflict over desire paths

I think it's equally as import to consider the context in which this specific "desire paths" debate is occurring because in general golang has philosophically preferred strong signage rather than paving paths. That is to say, historically, the language has preferred to let strong conventions dictate patterns rather cluttering up the language with "features" that enforce things that 99.9% of developers are going to do anyways.

[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 }

[thenorthnate]

@SteveRuble thanks for the additional thoughts! I agree that something like this would work more cleanly with the zero value returns that you mentioned. I think for the map example to make sense, you'd want something more like this:

func getOrDefault(m map[string]string, key string) (string, bool) {
  val, ok := m[key]; val, ok ?  // returns if val is non-zero or ok == true
  return "default", false
}

Or maybe with named returns, it could be closer to what you had:

func getOrDefault(m map[string]string, key string) (val string, ok bool) {
  // bare "?" evaluates the current state of the named return values perhaps... but the ";" I think would be needed
  // you could put a bare "?" on it's own line also in this syntax
  val, ok = m[key]; ?
  return "default", false
}

I suppose if you wanted to get something from a map OR get a default value, then maybe you don't care about testing for presence in the map so it could be simplified to just return a string:

func getOrDefault(m map[string]string, key string) string {
  m[key] ?
  return "default"
}

The way I was thinking about the idea was basically matching the structure that is currently used for channels. You pass a value into a channel. Sort of a stretch, but if the ? represented a sort of "return channel" (that accepted multiple values at once) and only executed if one of the values you passed into it was non-zero, then it makes the syntax a bit easier to reason about I think. I'm not suggesting this, but the way I'm thinking about it is like sending the values in the reverse direction of the current channel syntax like this:

val, ok -> ?

[mikeschinkel]

"I agree that errors are just values and it seems out of place to treat them inherently differently"

+1

"There are lots of special cases where that doesn't always work perfectly - the easiest one I can think of (admittedly not in the std lib) is in golang migrate where two errors are returned on close: https://pkg.go.dev/github.com/golang-migrate/migrate/v4#Migrate.Close"

Just a counterpoint.

I think the signature chosen for the Migrate.Close() method — as in almost all coding choices — was a case of happenstance.

One could argue that if returning two errors was more difficult than returning one error they may have chosen a different — and IMO better — signature, something like:

type MigrateError struct {
   SourceErr error
   DatabaseErr error
}
func (me *MigrateError) Error() string {
   return errors.Join(me.SourceErr,me.DatabaseErr).Error()
}
func (m *Migrate) Close() (err *MigrateError) {...}

The point I am trying to make is that it seems entirely reasonable to bake into the language the concept that if an error object is returned there should be only one and that it should be the last one listed. Doing that creates opportunity to streamline patterns and reduce complexity, much like how go fmt and implicitly-implemented interfaces streamline complexity.

IMO, of course.

[doggedOwl]

I agree that errors are just values and it seems out of place to treat them inherently differently

TBH to me it is just a slogan because in practice they are always treated differently.
See the very reason we are in this sittuation is because pretending they are just values like anything else has never worked. yes somethimes you can treat them the same but it's an exception rather than the rule.
Errors impact the flow of a program in ways that normal values does not so maybe it's time to forget about the slogan.

[thenorthnate]

Errors impact the flow of a program in ways that normal values does not

I agree that non-nil errors usually impact the flow of the program, but I disagree that "normal" values are less likely to! There are many cases where the program is in an "invalid" state because of the value of a non-error type variable.

• Checking for a nil pointer
• Checking for the presence of something in a map
• Doing data validation after you read in something from the outside world (empty strings, etc)

In most of those cases, the zero value is unexpected and causes a change in the flow of the program the same way an error would. If you write an HTTP handler that accepts JSON input for example, you'd check the one error returned via the unmarshal call, but then you might have several checks to ensure that the values you got aren't "0" before doing the work for that endpoint.

[mikeschinkel]

” Errors impact the flow of a program in ways that normal values does not so maybe it's time to forget about the slogan.”

Every guard clause impacts the flow of a program, and guard clauses other than err!=nil trigger directly or indirectly on values, yet I see no discussion of a special language feature for them.

So yes, treating errors as values gives the developer full control and keeps the language simple.

(I could envision a language feature for handling guard clauses but such a feature does not feel like something that would be consistent with the zeitgeist of the Go language.)

[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.

[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"

[dfawcus]

I think there's an argument to be made if it's hard to render syntax into a spoken language, English or otherwise, it's going to be harder to learn, remember, or talk about. Not a dealbreaker by any means, just something I was thinking about when reading through code examples.

100% agree. I think a human-language translation of ? is super important. Currently, it seems to mean different things to different people.

Read it as 'or_else', just as in the so named keyword in an Odin "or_else expression". It certainly fits the English idom :-)

[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.

[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.

[dfawcus]

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 is not so bad, but one of the issues I had was like this example, where for me the ? at the end of line 1091 was simply missed without re-reading 3 times.

https://go-review.googlesource.com/c/go/+/644076/1/src/cmd/go/internal/work/exec.go#1091

Hence why I'd view something akin to this as easier to spot, however that was achieved:

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
}

What that would mean for the cases with blocks following the test, I don't know.

[apparentlymart]

The concern about a lonely ? at the end being easy to miss has come up a few times in different parts of this discussion by now.

It seems like a particularly tricky detail of the proposal because it's an explicit goal of this proposal that the error path be easy to ignore when you're trying to ignore it -- that is, when you want to focus on the happy path. But several different readers (including me, somewhere else) have also observed that it can also be easy to ignore even when you aren't trying to ignore it, such as when you're trying to scan over all of the possible exit points for a function.

In some other place (possibly in the original discussion?) someone remarked that it could potentially be mitigated by making sure that the text editor integrations can highlight all of the explicit return statements and all of the implied returns from ? so that there is at least some way to emphasize all of the return paths temporarily when you want to. As usual with editor-integration-based solutions though, that doesn't answer for how it would work out in non-text-editor contexts, such as in code review tools.

As I think about potential alternatives that still try to preserve the idea that all of the error-related tokens get pushed to the right rather than to the left, the most minimal change to the proposal I could think of was to require a naked return keyword after the question mark in the case where there's no block:

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

This then uses the presumably-already-familiar return keyword, hopefully making it easier to notice when scanning over the code and, as a bonus, giving a clue to an unfamiliar reader that at least this language construct has something to do with returning, though of course they'll probably still need to go read some docs elsewhere to figure out exactly what it represents. This does, of course, come at the cost of an additional token of mandatory boilerplate, but I don't think it's a substantial amount of extra boilerplate.

If combined with the idea from another thread in this discussion of requiring an identifier after the question mark to name the error symbol for the optional block then this goes some way to solving disadvantages 2 and 4, making the longer form appear like this:

func compress(data []byte) ([]byte, error) {
    b := new(bytes.Buffer)
    gz := gzip.NewWriter(b)
    gz.Write(data) ? err {
        return nil, fmt.Errorf("writing: %w", err)
    }
    gz.Flush() ? err {
        return nil, fmt.Errorf("flushing: %w", err)
    }
    gz.Close() ? err {
        return nil, fmt.Errorf("closing: %w", err)
    }
    return b.Bytes(), nil
}

In this variation of the proposal, ? is never valid alone and must always be followed by some other token. If that token is the return keyword then we know that no subsequent block is expected. If that token is an identifier then we know that a subsequent block is expected. No other token type is valid in that position, including implicitly-inserted semicolons, and so accidentally inserting a newline before the ?, after the ?, or after its subsequent token always makes the program invalid rather than making it valid with a different meaning.

As a final little bonus consistency, regarding the other discussion about how one might read this language construct out loud, in this variation both forms of ? could be pronounced as "on error", with ? return being pronounced as "on error, return" and ? err { ... } being pronounced as "on error..." followed by however you'd normally pronounce what's written in the block.

Edit: I combined this idea with some other seemingly-popular variations from this discussion to produce a further iteration of Ian's proposal in #71528.

[alkapov]

I really like the given proposal. However, I feel like it tries to achieve too much at the same time. What do you think if we differentiate between error context wrapping and full error handling? This would allow us to focus on simplifying the most common case: adding context during error propagation. I think a dedicated keyword like retwerr "something failed: %w" for wrapping and reterr for simply returning the error would be a good starting point. And I like the idea of concise syntax, but I think the ? operator, especially with an optional block, conflates context wrapping and full error handling. It also feels less aligned with other control flow mechanisms that Go provides. This separation keeps things simple and avoids mixing context wrapping with more complex error handling logic. What do others think?

// fmt.Errorf("something else failed: %v", err)
r := SomeFunction() retwerr "something failed: %v"

// fmt.Errorf("something else failed: %v", err)
SomeFunction2() retwerr "something else failed: %v"

// err
SomeFunction2() reterr

In this case, there is no way to directly access the err variable because we specifically don't want to handle it at this point. We're only adding context during propagation. This approach would not solve the idea of having a continue block for errors, as that seems like full error handling and should be explicit. The retwerr/reterr proposal focuses solely on context addition, not control flow changes related to error handling.

Grey areas:

• Struct initializing: Inlining reterr within struct initialization, like foo = Foo{Bar: NewBar() reterr}, feels too complicated and blurs the line between context wrapping and object construction.

• Error annotation/Custom errors: Introducing error annotation or custom error seems to overlap with full error handling.

  type ErrorWrapper interface{ Wrap(error) }
  
  // CustomErr implements ErrorWrapper
  r := SomeFunction() retwerr CustomErr{}

  What happens if CustomErr.Wrap ignores the original error? Well, the same problem can occur with string literals.

• String literals vs. expressions: Should we allow only string literals in retwerr or also string expressions? I think both are acceptable. If expressions are allowed, the arguments should be evaluated in the same way as they are for defer statements.

[smyrman]

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.

If I understand the proposal correct. You also can't use the proposal to assign fields inside a struct. E.g. the following would not be allowed:

func formatX(somepkg.X) (string, error)
func formatY(somepkg.Y) (string, error)

func ToDestStruct(src somepkg.SrcStruct) (DestStruct, error) {
    var errs []error
    dest := DestStruct{
        X: formatX(src.X) ? { errs = append(errs, fmt.Errorf("x: %w")) }, // not allowed
        Y: formatY(src.Y) ? { errs = append(errs, fmt.Errorf("y: %w")) },  // not allowed
    }
    if err := errors.Join(errs...); err != nil {
        return DestStruct{}, err
    }
    return r, nil
}

We have a lot of code that implement some variation of this in our own code base. I personally feel that if the syntax was allowed inside struct initialization, it would significantly increase the value of the proposal.

Real examaple:

Below is a slightly modified example from our own code-base:

// scatterPlot describe the API layer transport model for the scatter plot type. 
type scatterPlot struct {
	Type    string           `json:"type"`
	Color   string           `json:"color"`
	Opacity int              `json:"opacity"`
	X       scatterPlotAxis  `json:"x"`
	Y       scatterPlotAxis  `json:"y"`
	Size    *scatterPlotAxis `json:"size"`
	Hue     *scatterPlotAxis `json:"hue"`
}

// toBusinessScatterPlot validates and converts a scatter plot transport model to
// it's business layer representation. Validation errors are aggregated into a
// [bend.PathErrors] instance.
func toBusinessScatterPlot(v scatterPlot) (visfield.ScatterPlot, error) {
	eb := bend.NewErrorBuilder()
	color, err := textfield.ParseColor(v.Color)
	if err != nil {
		eb.Field("color").Error(err)
	}
	opacity, err := visfield.ParseOpacity(v.Opacity)
	if err != nil {
		eb.Field("opacity").Error(err)
	}
	x, err := parseScatterPlotAxis(v.X)
	if err != nil {
		eb.Field("x").Error(err)
	}
	y, err := parseScatterPlotAxis(v.Y)
	if err != nil {
		eb.Field("y").Error(err)
	}
	size, err := parseScatterPlotAxisOptional(v.Size)
	if err != nil {
		eb.Field("size").Error(err)
	}
	hue, err := parseScatterPlotAxisOptional(v.Hue)
	if err != nil {
		eb.Field("hue").Error(err)
	}
	if err := eb.BuildError(); err != nil {
		return visfield.ScatterPlot{}, err
	}

	return visfield.ScatterPlot{
		Color:   color,
		Opacity: opacity,
		X:       x,
		Y:       y,
		Size:    size,
		Hue:     hue,
	}, nil
}

How this could look like with the described proposal, if it was allowed:

func toBusinessScatterPlot(v scatterPlot) (visfield.ScatterPlot, error) {
	eb := bend.NewErrorBuilder()

	v2 := visfield.ScatterPlot{
		Color:   textfield.ParseColor(v.Color)        ? { eb.Field("color").Error(err) },
		Opacity: visfield.ParseOpacity(v.Opacity)     ? { eb.Field("opacity").Error(err) },
		X:       parseScatterPlotAxis(v.X)            ? { eb.Field("x").Error(err) },
		Y:       parseScatterPlotAxis(v.Y)            ? { eb.Field("y").Error(err) },
		Size:    parseScatterPlotAxisOptional(v.Size) ? { eb.Field("size").Error(err) },
		Hue:     parseScatterPlotAxisOptional(v.Hue)  ? { eb.Field("hue").Error(err) },
	}
	
	if err := eb.BuildError(); err != nil {
		return visfield.ScatterPlot{}, err
	}
	return v2, nil
}	

[SteveRuble]

@smyrman, you can do something like that already with the existing language:

func ParseAdapter[In any, Out any](in In, errs *error, parse func(In) (Out, error)) Out {
	out, err := parse(in)
	if err != nil {
		if errs == nil {
			*errs = err
		} else {
			*errs = errors.Join(*errs, err)
		}
	}
	return out
}

Usage:

var err error
v2 := visfield.ScatterPlot{
	Color:   ParseAdapter(v.Color, &err, textfield.ParseColor),
        //...
      }
if err != nil { 
  return err
}

If you want to do something else with the errors besides collect and return them, implement ParseAdapter differently.

[ianlancetaylor]

@smyrman Yes, that would be easier, but as you say it doesn't seem to allow for the early return. That approach moves more toward the rejected try proposal (#32437).

[smyrman]

Thanks for going through the example @apparentlymart. Sorry for not explaining the ErrorBuilder, or replacing it with something easier to understand, but you assumption about how it works in relation to state is correct.

Since I didn't replace it, I'll explain it briefly. It essentially joins the errors with path information in eb and return an aggregated error with path information of each error. eb.Field(string) returns a branched error builder that let's you add errors at that particular path.

In reality though, when used like in the example, it's just a glorified alternative to append and a custom version of errors.Join"

// Error builder syntax:
eb := bend.NewErrorBuilder()
eb.Field("x").Error(err) 
return eb.BuildError()

// Equivalent functionality with append & join based syntax:
var errs []error
errs = append(errs, bend.PathError{Field:"x", Err: err}) 
return bend.JoinPathErrors(errs) // specialized variant of errors.Join

@SteveRuble, I actually did something like that for a while. Although it looked like this.

// C allows collecting an error into an ErrorBuilder instance and return
// the value. Intended use-case is to collect errors from functions that return
// both a value and an error: func(...) (T, error).
//
// Usage (Assuming Parse(T1) (T2, error)):
//
//	eb := bend.NewErrorBuilder()
//	v := bend.C(Parse(input))(eb.Field("a")) // Collects error return to eb, returns value return.
func C[T any](v T, err error) func(ErrorBuilder) T {
	return func(eb ErrorBuilder) T {
		eb.Error(err)
		return v
	}
}

So the usage would become:

eb := bend.NewErrorBuilder()
v2 := visfield.ScatterPlot{
	Color:   bend.C(textfield.ParseColor(v.Color))(eb.Field("color")),
	//...
}
if err := eb.BuildError(); err != nil { 
  return visfield.ScatterPlot{}, err
}
return v2, nil

However, In practice I find it hard to read. So we converted back to:

color, err := textfield.ParseColor(v.Color); err != nil {
	eb.Field("color").Error(err)
}

In the end, no matter how it's done, the error handling need to be clear.

[smyrman]

@smyrman Yes, that would be easier, but as you say it doesn't seem to allow for the early return. That approach moves more toward the rejected try proposal (#32437).

Thanks for the link. Yes, there probably would be some similarities; maybe enough that some of the disadvantages have been mapped out.

I was thinking you could also allow an early return with allowing alternate declarations:
?(handler func(error) error) -- return from parent function if handler returns an error; use zero-values for other returns.
?(handler func(error) (T1, ..., TN, error)) -- declaration with full return list

For inline definitions of the handler func, this will make for a longer syntax than ? { .... }. But more useful if this is good enough for it to pass as an expression.

It could maybe also help avoid Disadvantage 4; I.e. since

myFunc
(a)

is well understood to not mean

myFunc(a)

I am sure it has some other disadvantages, though.

In the end, I am mostly just interested in communicating the use-case.

[AndrewHarrisSPU]

@smyrman

In the end, I am mostly just interested in communicating the use-case.

I think your use case is interesting. It strikes me as an example of stylistic differences in much of the standard library, in contrast with applications - the purposes differ, and that affects style. My sense is that applications - especially around data-to-data translations, in polyglot environments - tend to more often have things like ErrorBuilder to coordinate patterns.

Just riffing - it made me wonder if there's blockless-?, block-?, and also a case-? that looks like a bit like a switch or select case, for the one-liners.

	plot.Color = textfield.ParseColor(v.Color)
		?: eb.Field("color").Error(err)
		
	...
	
	eb.BuildError()
		?: return

[AngeloChecked]

I like the shorthand syntax when the error is trivial and I want instant propagation without distracting from the happy path:

val := doSomething() ?

But I'm not sure this syntax provides enough benefit over the traditional if err != nil {} when we need to manipulate or handle the error:

val := doSomething() ? {
  return nil, fmt.Errorf("event x caused error: %w", err)
}

// vs

val, err := doSomething() 
if err != nil {
  return nil, fmt.Errorf("event x caused error: %w", err)
}

my 2 cents

[dmitryuck]

The idea here is not to limit by only error handling using ? operator, also use it for checking ok/!ok

m := map[int]int{}
v := m[0] ? {
// in case !ok
}

and several other aims

[QuantumGhost]

This has been discussed, see "Supporting other types" in the proposal.

[peakedshout]

I am extremely opposed to this proposal, even if I am called a "stubborn person".
The addition of this ? is undoubtedly adding a heavy degree of syntactic sugar. I have written many languages, and the degree of syntactic sugar in Kotlin is undoubtedly "excessive sugar".
So I don't want Golang to introduce such a high-sugar "feature".
Error handling is an issue that every developer should deal with head-on. Although writing these logics is very boring, the flat logic is always reminding the writer and the reader: "There is an error here".
When ? appears to simplify this logic, it is just an "escape" behavior.
In today's development environment, I don't think that two more lines of code will affect the coding experience. (In my opinion, they just ignore the basic logic of processing in order to write less code)

Obviously, I can't change anything on my own, but I will always resist this way of writing. (If the ide recommends this way of writing to me, I guess I will throw it into the trash can)
Golang has escaped from the try catch hell, but it should not enter another hell.

[ijxy]

Rare cases of err blindness occur, for example as identified by #71432 and #20148.

Imagine how much more "err blindness" there would be if it were trivially easy to ignore errors. Lots more.

[mikeschinkel]

@apparentlymart —

"At various points in this discussion I've seen references to having one error variable per function and using goto to jump to a single return statement per function. Of course I had a general idea of what that would look like, but I was curious to study a real example and so I took the liberty of reading some of the Go-language repositories from @mikeschinkel."

I practically choked up when I saw you found and posted a great example of the pattern I have been advocating for from one of my repos. That action revealed a generosity of spirit you possess that is exceeding rare in today's world.

Thank you.

"I personally find this structure quite readable, although I hope you'd agree that it's somewhat unconventional: most Go code I've encountered does not follow this pattern."

I completely concur it is currently unconventional.

When I need to collaborate with others on a project I can rarely get others to even consider it — which I attribute to the long-held dogma that goto is inherently bad — so I do not get to use the pattern on those projects. That results in those projects being less maintainable than they otherwise could be (I will elaborate on the benefits of the pattern at the end of this comment.)

OTOH when I am working on my own projects, on an individual project, or am the lead on a team I use the pattern and reap its benefits.

"I don't mean this to say that this structure is wrong by any means; only that it seems relatively unusual compared to most Go code I encounter in my work."

And I especially appreciate that you chose not to characterize it negatively, other than to correctly note it is not widely used.

"Nonetheless, I do now see what you mean about this being somewhat harder to express using the proposal that this overall discussion was about, particularly in its original form which automatically declares a local variable named err."

Again, thank you.

"Here's an attempt at rewriting it using the variation where a variable name appears before the error-handling block, which at least allows it to have a different name then."

Yes, you nailed it.

Unfortunately that approaches requires two (2) named vars, one name being defacto-standard while the other would be a name for which there is no well-known or obvious name to use. It would also request yet another line of boilerplate for every place ? {...} error handling is used.

The upshot is that the added boilerplate makes the pattern harder for get to even consider trying it, and that would makes it much harder for me to use on projects. And people who are unwilling to try it will never discover the many benefits of the pattern I discovered.

That is why — in addition to whatever form collectively makes everyone else the most happy — I am just asking for the ability to use ? goto err and a built-in error() function that would return the last error value captured by a ?. Most would ever even see code that uses it, but it would allow me and those who recognize the benefit of the pattern to use with the reduced boilerplate of using ? rather than force me and others to keep swimming upstream.

"This version ended up having the same number of lines as the original because it traded the if err != nil lines for err = thisErr lines. I don't really have any strong opinion about whether this example is better or worse... it just seems different."

The fact it requires a 2nd func-scoped error variable without an obvious name makes this approach a non-starter. To me, at least.

"Now here's a variation of it with the style of early return that the original proposal seemed to be aimed at:"

That variation is in my view an alternative to using goto, not something that could be used with my goto pattern.

That approach also requires maintaining consistency across two (2) declarations and :

• Three (3) other lines with six (6) total return values, versus
• One (1) line with just two (2) return values.

But it gets a lot worse when you have 10+ early returns per func, and up to six (6) return values in those funcs. Then it looks like this:

• Ten or more (10+) other lines with sixty (60) total return values, versus
• One (1) line with just six (6) return values.

And yes, I have worked on two (2) client projects where abominations like that were not uncommon.

When all return values are declared with unique types the compiler can catch most bugs, but if any of those return vars share types side-by-side — which I also found to be common — it is all too easy to wrongly order return statement values, and introduce insidious bugs.

(I would be all for Go disallowing more than three (3) return values, but I digress.)

In both of these latter examples, one needs to find and read all of the return statements to confirm that all of them do indeed set the first return value to the first result from getFeed. The first two examples, by contrast, have only a single return statement and so reaching that conclusion instead involves finding all of the statements that assign to feed, of which there is only one in each of these examples.

Yes!

"Regardless of the subjective merits of these different styles though, if the discussion in this proposal (with the modification of the explicit error variable name) were accepted then I believe all four of the examples above would be valid, so it would still be possible for someone who prefers the first or second example to write functions in those styles. All of them seem relatively readable to me, and I think that's largely a consequence of this function being relatively short and thus it's easy to quickly scan and imagine all the possible control flow paths."

Of course you are correct that all four (4) would be valid.

But the third is an early return pattern so I don't see how it applies here.

And latter would be so tedious to use as to discredit it from being considered a usable pattern.

"I find myself agreeing then that short functions are typically easier to read, and that seems to be true regardless of the fine details of how they are written. Whether reducing the boilerplate would encourage writing more complex functions (that could therefore be harder to read) is an interesting question, but I don't think that's self-evident. 🤔"

Note to me it is not "reducing boilerplate" that is the culprit but instead features that allow minimizing complexity across longer functions, which block scoped variable exactly do.

That argument is self-evident to me, but of course that could be my confirmation-bias speaking.

Still, it seems you could at least theorize both that certain features encourage writing more complex functions and that longer functions are harder to read? And if you agree to theorize, what would you require to accept those theories as proven (or disproven?)

"The passing note about breakpoint debugging above seems interesting. @mikeschinkel. Are you thinking of a situation where you want to set a breakpoint that would fire when that function returns, regardless of how it returns? I can see how that would be trickier when there is more than one return statement, indeed."

Exactly!

I have submitted a feature request for my IDE vendor JetBrains to breakpoint all return statements in a func whenever I breakpoint any return statements in that func, but they have neither seen doing so as a priority nor even let me know if they would be willing to add such as feature.

If they did add easy ability to breakpoint all return statements that would at least be one fewer reason to prefer the goto pattern that makes using single returns viable, but we do not know if there is a day they will ever do so, and even so that day is not today.

"Unfortunately I'm often debugging code that was written by other people..."

Yes. I frequently use debugging when I am trying to understand the behavior of code written by other people, and I only ever experience the problem with breakpoints and multiple returns in other people's code as I stick to single returns in my code. For example, I was just debugging through go mod tidy yesterday.

But if the Go team makes error handling when multiple returns are used a lot easier then the inertia would likely be so great I would find myself having to deal with breakpointing a lot more multiple returns, especially when working collaboratively with others. And that is a future I really hope I get to avoid.

---

BTW, a bit of history about my Go journey to hopefully help you appreciate how I came so zealous in my advocacy for goto error handling. When I first started with Go I would use my deprecated go-only package with a for only.Once{...if err!=nil { break } ...} construct to wrap all code in each function that generated an error.

My only reason for using go-only was for a single return statement to aid breaking debugging.

Then when speaking with one of my clients — who is an expert-level C programmer — he asked me why I did not just use goto instead of adding the complexity and non-standard nature of go-only? My knee-jerk reaction was "No! Goto is considered harmful!"

My client then pointed out that C developers have long used goto for error handling, and that there was nothing wrong with using goto for use-cases where it excels.

So I cautiously started using goto end and end:. But I soon discovered that using this goto pattern made my coding a lot easier and more consistent. goto made it easier to refactor too-long funcs into short funcs and to combine too-short funcs into longer ones without having to modify any of the contained logic. This greatly reduces the potential to introducing logic bugs when refactoring.

I also found that using goto combined with a single-label constrain meant that my code would "tell me" when a function was too long, and that I needed to refactor it. Such decisions are no longer subjective.

After using the goto pattern for almost five (5) years now, my original motivation to use the pattern — to improve breakpoint debugging — now pales in comparison to the maintainability, robustness, and ease of development I find when using goto for error handling.

I just wish I could convince more people to try the pattern for long enough that they can discover it benefits, too.

BTW, I documented the benefits of the pattern here. Pay special attention to those benefits I denoted as "Longer term."

[mikeschinkel]

@AndrewHarrisSPU

The problem with said "shrinkwrapping" is that it naturally makes error handling like a hammer; when by far the easiest tool to reach for when an error occurs is an early return, early returns end up being what (practically) every error will use.

We really could use ? for "(practically) every error"! I think that something like ? could be good for readability, and I've definitely moved towards thinking "this should be everywhere" over the course of the proposal / discussion.

I think maybe my lack of explicitness maybe caused you to misunderstood what I was trying to convey with my metaphor.

I agree that "We really could use ? for (practically) every error"!"; the ? was not was I was calling a hammer. The hammer I was referring to is the early return.

See @apparentlymart's gracious analysis of why early returns can be problematic: #71460 (reply in thread) and #71460 (reply in thread)

Too bad Go seems to be trending towards making one err var declaration and scope per func harder by proposing functionality that proliferates multiple err var scopes within the same func.

I'm not really concerned about this, I guess. I don't see why we would want to avoid handling more than one error condition per function where it would otherwise make sense.

Again, I think my wording may have caused you to misunderstand what I was trying to convey. I was not at all arguing against multiple error conditions per functions; they are in-fact a fact of programming life.

Instead I was arguing against making it easier to manage the complexity of longer functions. Specifically I was referring to the block-local scope of the proposed error handling blocks.

---

If I were king I would pronounce that Go must deprecate block local scoping and variable shadowing because of the potential for bugs they enable and the complexity they empower within a func, and then just let everyone deal with the backward incompatibility.

Kidding. Not kidding.

[AndrewHarrisSPU]

If I were king I would pronounce that Go must deprecate block local scoping and variable shadowing because of the potential for bugs they enable and the complexity they empower within a func, and then just let everyone deal with the backward incompatibility.

FWIW I think Zig did this, but it also doesn't really have lexical closures. I'd love to address err shadowing such that one never has to worry about the difference between function and block scope. I also love lexical closures.

There's an interesting example of function-scoped err, shadowing and lexical closures if we think about rewriting (*Data).readType method of src/debug/dwarf/type.go with ?, which you mention here. To me this is peak Go - it's pattern matching with side effects, recursive invocation, memoization, lexical closures, etc. And, it's a pretty imperative feel. FP purist might be tempted to break their own rules, or incur some complications to write something like this without getting too opaque. I think the end result could have some modest readability gains.

(I'd agree goto Error is really clutch here, no objection to goto. But I think it's most useful because it's an escape hatch inside nested switch/loop/conditionals; that it coincides with error management is more incidental. There are some early returns before the Error label comes into play. I'm definitely impressed that I probably don't think about goto Error often enough, but I'm still not quite persuaded it's a silver bullet, nor that single-exit is a silver bullet.)

---

Hypothetical rewrite diffs:

err is currently declared for the first time on line 412, but this could be eliminated with ?.

// line 412
e := r.Next() ?

To compensate we can declare err at tighter location, lexically. The appearance of var err error at function scope is a very strong hint that the code is doing something more interesting with err than usual.

// before line 442, insert:
var err error

Immediately afterwards, next and typeOf are declared, which close over err and mutate it as a side effect. If we're strictly avoiding shadowing, we add tokens relative to the original, but it's also a bit more explicit inside next and typeOf that we are bubbling the error up via side effects.

// line 452
kid := r.Next() ? rNextErr {
    err = rNextErr
    return nil
}

// line 485
t = d.readType(name, r.clone(), toff, typeCache, fixups) ? readErr {
    err = readErr
    return nil
}

// line 489
t = d.sigToType(toff) ? sigErr {
    err = sigErr
    return nil
}

On line 499 a very big switch begins, and the Error label comes into play. Inside the big switch, err is mutated:
- 4 times by for kid := next(); kid != nil; kid = next() loops
- 7 times by ... = typeOf(e) calls
- 12 times by switch logic, constructing a DecodeError de novo, explicity mutating err and jumping to Error. No ? rewriting.
- 1 time irregularly (line 667)

For ? usage, it isn't necessarily doing much but the expression-is-a-statement rule means we can use ? as a convention. There's edges to block-? scoping with an already existing err identifier that are a little strange here, perhaps - _ and bErr

// line 512
t.Type = typeOf(e); err ? _ {
    goto Error
}

// line 667
b.err ? bErr {
    err = bErr
    goto Error
}

Finally, any remaning case of err is handled.

// line 831
err ? _ {
    goto Error
}

---

(edit): This example does suggest ? [IDENT] { over ? { to achieve the no-shadowing outcome. Maybe the rule could be ? { declares err unless it shadows.

[mikeschinkel]

"FWIW I think Zig did this, but it also doesn't really have lexical closures."

Yeah, Zig has been on my radar more and more. Depending on how Go evolves I might be tempted to consider moving my work to using Zig instead.

"I'd love to address err shadowing such that one never has to worry about the difference between function and block scope. "

I really would, too.

OTOH our desired respective prescription differ greatly.

"I also love lexical closures."

That makes one of us.

"To me this is peak Go - it's pattern matching with side effects, recursive invocation, memoization, lexical closures, etc. "

Two things stand out and both are negatives. 453 lines and six (6) levels of nesting make that func really, really hard to follow.

I have two )2) constraints I try to embrace as I code:

1. No more than two (2) levels of nesting, or three (3) is absolutely required, and
2. Shorter, more cohesive, and easier to reason about funcs.

What I have found about the goto pattern is it makes the former much easier to accomplish, and by its very nature the code "tells me" when a function is too long That is a benefit I think you cannot appreciate until after you have experienced it for a while.

(I'd agree goto Error is really clutch here, no objection to goto.

+1

"But I think it's most useful because it's an escape hatch inside nested switch/loop/conditionals; that it coincides with error management is more incidental."

I think of the pattern as the best way I have found to implement guard clauses, where most guard clauses are triggered by an error being returned.

"There are some early returns before the Error label comes into play. I'm definitely impressed that I probably don't think about goto Error often enough, but I'm still not quite persuaded it's a silver bullet, nor that single-exit is a silver bullet.)"

I am not surprised. Nobody I know who has not tried the pattern for at least several weeks has ever been persuaded AFAIK. But of the few that I have been able to get to try it for a least several weeks, none of them will go back from what they've told me. Admittedly though, that is a very small number of people thus far.

"Hypothetical rewrite diffs:"

I really do appreciate the time and effort you took to find such a func and then to refactor it. Sincerely.

OTOH, the requirements for more boilerplate to manage a custom named error var breaks the ability to refactor code without potentially introducing bugs when using this goto pattern. That neuters what I consider to be the primary benefit of the pattern — let alone the fact it requires more lines of boilerplate — so the approach you presented is a non-starter to me. One might as well give up using a controversial technique if they don't get the primary benefit, right?

I performed a first-pass refactor on the readType() func to illustrate how the goto pattern would apply using current Go 1.24 capabilities. You'll note I added three (3) new private types and thirteen (13) new private funcs as part of this refactor. Almost all of those funcs also use the goto pattern themselves, except for the ones that have no need for any guard clauses.

I think this version is much easier to understand, and would likely be much easier to maintain; would you not agree?

I also refactored again, but just the readType() func (too much work to refactor all the other funcs again) I used the naked ?, my proposed error() func and my proposed error {...} block (note I still needed an goto end though.) This version reads even better, no?

BTW, I am aware readType() might have been optimized by the Go team for performance and not for maintainability nor for understandability. But since we are discussing error handling patterns and not performance or original intent I think we can safely ignore that for now, right?

Also, my refactor might have introduced a few bugs. I cannot be sure because I had to modify the logic in several places and I may have gotten the logic wrong. OTOH, had the original version been written following the goto pattern with the constraints I mentioned above then I contend that I would have been able to refactor from a 453 line func to a 111 line func without potentially introducing any logic bugs because code would not need to be changed[1], only moved.

Think of using this goto pattern as similar to the constraints of the REST architecture where you can only have a predefined set of methods; GET, POST, DELETE, etc. Following this pattern your code structures all start looking and behaving the same and you can spend more time solving the business problem and less time thinking about how to structure the code.

-Mike
P.S. If there is ever a chance you would try the pattern I advocate for please reach out to me via the Gopher slack so we can have a chat or better a screenshare and I can get you started with how the pattern works best. (I have written blog posts about it but I have had zero success with that. I have only had success from one-on-one screen share coaching. My hope is that I can coach enough people on this topic so that others will finally become evangelists for it, too.)

[1] Two caveats to my "would not need to be changed" assertion, both which could be fixed by the Go team if they were motivated to do so:

1. proposal: spec: permit goto over declaration if variable is not used after goto label #26058
2. proposal: spec: Mixed Declaration-Assignment Operators in Multi-Variable Assignments #71522

[Melkeydev]

While the ? syntax effectively reduces boilerplate, I'd like to propose an alternative that may improve readability and align better with Go’s existing conventions. This is also inspired by another language, and the verbosity is definitely taken else where.

Instead of:

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

I propose:

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

Rationale:
on_error is very verbose, I agree, but I believe it does achieve what the author originally wanted which is to remove boiler plate.
I don't like the dependence on an operator like ?, but maybe a keyword like on_error to bubble up any errors if a function responds with one could be a better strategy?

[mikeschinkel]

"You mean C's errno?"

No, not a macro, not an int value, a func that returns a value that implements the error interface.

And if you still say "No thanks," care to give your justifications for such an approach would be bad?

[ijxy]

"You mean C's errno?"

No, not a macro, not an int value, a func that returns a value that implements the error interface.

And if you still say "No thanks," care to give your justifications for such an approach would be bad?

For the same reason that all implicit things are bad: they are indeterministic and make any code that they interact with indeterministic.

Introducing indeterminism for "minor syntactic convenience" (ie foregoing writing if err != nil) is simply a terrible trade. There is nothing you could do with your supposed error() function that you cannot already do, except doing it wih Go as it is will be explicit and clear to read.

Go is so good because it is so easy to reason about (usually). Anything that jeopardizes that is a loss.

[mikeschinkel]

"For the same reason that all implicit things are bad: they are indeterministic and make any code that they interact with indeterministic."

I realize that I had an idea for error() but I did not explicitly communicate how it would work. As I envision it error() would be implemented by the compiler with lifetime scope equivalent to a func-scoped variable in a manner very similar to how recover() that is already in Go works. This error() func would not behave like any other, except recover().

Maybe you naturally assumed standard func behavior, and that is why you had an immediate negative reaction?

For this concept, each func would get its own error value on the local stack to be returned by error() and initially that error value would be nil. Whenever an error is returned by an expression that uses the error trigger syntax — be it || or ? or something else — Go would put that error value on the stack where error() can retrieve it. It would work like the following:

func Inner() {
   errors.New("we have an error") || {
      err := error()
      println(err.Error()) // Prints "we have an error"
   }
}
func Outer() {
   Inner() // First call Inner() that assigns an error to its error()
   println(error())  // Prints nil, i.e. this scope is not affected by the error generated inside Inner()
}

So the error() function as I am envision it would be no less deterministic than the value contained in a named err variable.

As you can hopefully see, this error() would behave very differently from errno in C.

Given the behavior as I have described it here, do you still hold the same negative opinion regarding a potential built-in error() func?

And if you still hold the same opinion, can you give a use-case where having such an error() built-in would actually cause a problem? One that would differ from using a named err variable? And a problem that recover() would presumably have as well?

[ijxy]

func Outer() {
   Inner() // First call Inner() that assigns an error to its error()
   println(error())  // Prints nil, i.e. this scope is not affected by the error generated inside Inner()
}

Your example is an example of precisely what I find to be problematic. There is no way to now that Inner() will set an error implicitly without digging through the code. If Inner() calls InnerInner() which calls InnerInnerInner() and so on... you cannot reasonably hope to follow the flow. It facilitates laziness only.

The implementation without error() is just objectively clearer, simpler and thus better.

func Outer() {
   err := Inner()
   println(err) 

   // no comments are needed because it's obvious
}

[mikeschinkel]

@ijxy —

"Your example is an example of precisely what I find to be problematic. There is no way to now that Inner() will set an error implicitly without digging through the code."

Your reply indicates that either you:

1. Were not able to understand what I explained — (maybe I explained it poorly again?),
2. Did not read and/or consider the comments I wrote in my code examples, and/or
3. Did not read my explanation enough to understand it.

Let me restate: There would be absolutely no reason — given how I explained that error() could work — that you would need to know that Inner() will set an error implicitly any more than you need to know when Inner() explicitly sets any func-scoped var.

As I explained, error() would behave exactly like how a func-scoped var — each func would have its own value for error() and having Inner() setting error() would not effect in any way the value returned by error() within the lexical scope of Outer().

That is no different than having an explicitly declared err in Inner() and explicitly declared err in Outer(); they are orthogonal and do not affect each other. Similarly if InnerInner() declared an err and InnerInnerInner() declared an err, none of them would (even be able to) affect the other err vars. Same would be true for this error() func.

"The implementation without error() is just objectively clearer, simpler and thus better."

Yes, but it is a lot more boilerplate — and no matter your or my subjective opinion on the topic, the one objective fact we cannot debate is that tied for the number two biggest challenge Go developers face of those who have participated in the Go community polls — is error handling in Go. And the number one challenge is learning how to use Go, which is not directly actionable like improving error handling is.

So realistically, whether we like it or not, the Go team needs make some type of change to improve error handling.

And the hypothetical error() func as I have explained is no less clear, no less simple and no worse than recover(), which is already in Go and not something I see anyone anywhere complaining about.

[soypat]

The Go team does not have to ask for permission to implement the rewrite tool so that it changes code visualized, but not the actual code saved in the editor.

If this really is wanted and disliked by large portions of the go ecosystem (seems to be almost 50/50) then maybe it makes sense to compromise and implement IDE visualization tools which do not affect the actual code.

[doggedOwl]

note that the rewrite tool is not part of this proposal. No rewrite will be forced on the go users even if accepted.
That was done to illustrate the effect that the new syntax could have if devs choose to write in that style,

[lainio]

I have played with the proposed compiler for some time and want to highlight a few concrete examples from the Go standard library. IMO, the proposal doesn't just reduce boilerplate—it also enables reusable patterns that improve skimmability and maintainability.

For instance, the net/mail package contains a helper function (parseSingleAddress) where multiple error checks clutter the (simple) logic. With the ? operator, we can introduce a generic expect helper, making the function significantly more skimmable. (expect could be used for map, type assert, etc.)

The updated version:

func (p *addrParser) parseSingleAddress() (*Address, error) {
     addrs := p.parseAddress(true) ?

     expect(p.skipCFWS(), "mail: misformatted parenthetical comment") ?
     expect(p.empty(), "mail: expected single address, got %q", p.s) ?
     expect(len(addrs) != 0, "mail: empty group") ?
     expect(len(addrs) <= 1, "mail: group with multiple addresses") ?
     return addrs[0], nil
}

This approach reduces visual noise while preserving explicit control flow, making it easier to scan for error conditions.

But let's have a more suitable example, first, produced by the ? migration tool:

func (tw *Writer) AddFS(fsys fs.FS) error {
	return fs.WalkDir(fsys, ".", func(name string, d fs.DirEntry, err error) error {
		err ?

		if name == "." {
			return nil
		}
		info := d.Info() ?

		// TODO(#49580): Handle symlinks when fs.ReadLinkFS is available.
		if !d.IsDir() && !info.Mode().IsRegular() {
			return errors.New("tar: cannot add non-regular file")
		}
		h := FileInfoHeader(info, "") ?

		h.Name = name
		tw.WriteHeader(h) ?

		if d.IsDir() {
			return nil
		}
		f := fsys.Open(name) ?

		defer f.Close()
		_, err = io.Copy(tw, f)
		return err
	})
}

It's much easier to skim than the original. But with the second version, we can do even more with the ? and expect:

func (tw *Writer) AddFS(fsys fs.FS) error {
	return fs.WalkDir(fsys, ".", func(name string, d fs.DirEntry, err error) error {
		err ?
		expect(name != ".", nil) ?

		info := d.Info() ?

		// TODO(#49580): Handle symlinks when fs.ReadLinkFS is available.
		expect(d.IsDir() || info.Mode().IsRegular(), "tar: cannot add non-regular file")

		h := FileInfoHeader(info, "") ?
		h.Name = name
		tw.WriteHeader(h) ?

		expect(!d.IsDir(), nil) ?

		f := fsys.Open(name) ?
		defer f.Close()
		io.Copy(tw, f) ?
		return nil
	})
}

Lessons learned while playing with ?

After experimenting with ?, one thing stands out: it feels natural. The more you use it, the more you expect certain patterns to "just work."

For example, when a function ends with io.Copy(tw, f) ?, it feels intuitive that no further return is needed. But of course, the compiler still requires it:

	io.Copy(tw, f) ?
	return nil
})

Interestingly, if you leave out return, the compiler doesn't throw an error—it just panics with:

<unknown line number>: internal compiler error: panic: unreachable

(FTR, I tested with the optional block, and the result was the same.)

Now that we have a standard way to propagate errors, we can build on it.

• Break on error, debugger feature
• error tracing (like Zig), tool or package
• expect runtime/testing awareness, package
• panic support, language

? isn't just syntactic sugar—it's a foundation for better error handling, tooling, and observability in Go. We've been stuck in a loop rejecting past proposals for years—it's time to move forward.

[mukunda-]

With the ? operator, we can introduce a generic expect helper

Just wanted to reinforce this as I brought it up somewhere else in this sea of discussion. I use the same pattern and I find it very effective, except right now I have to use panics to achieve the returns. The wonder of this proposed ? is that we can achieve a specific return behavior with minimal code overhead. To otherwise return, you need to type it out, as well as check a condition.

If we want to consider a larger scope here, it's macros. I like the quote at the top of the Metaprogramming chapter in The Pragmatic Programmer ("No amount of genius can overcome a preoccupation with detail" - Levy's Eighth Law). Avoiding "magic" is nonsense, IMHO. Less lines or tokens of code to express intent is much more important than enforcing "clarity" at the lower/primitive level in a complex codebase. One place I especially wish for more "shortcuts" is when writing test code (which, I'm sure you have seen, can eclipse the implementation). The proposed ? is a glimpse of the benefit of macros.

[ijxy]

? isn't just syntactic sugar

With optional blocks, ? turns Go into a whitespace-sensitive language. That is a very big price to pay for anything; I would consider it a breaking change since it can break existing (valid) code.

Without optional blocks, ? err { ... } is basically identical to if err != nil except with non-standard (ie confusing) variable declaration.

func doThing() (int, error)

// declaration is obvious
val, err := doThing() 
if err != nil {
  return err
}

// declaration is non-obvious
// you would not expect this given how _every other_ declaration works in Go
val := doThing() ? err { 
  return err
}

Adding significant language complexity to save net 2 tokens (if err != nil = 4 tokens, ? err = 2 tokens ) per error seems like a terrible trade-off.

[mikeschinkel]

"turns Go into a whitespace-sensitive language. That is a very big price to pay for anything; I would consider it a breaking change since it can break existing (valid) code."

On that point I concur.

"Without optional blocks, ? err { ... } is basically identical to if err != nil except with non-standard (ie confusing) variable declaration."

Not true.

The proposal allows for three (3) lines instead of four (4), and it more natural to type ? err than to type <enter><tab>if err !=nil.

That line reduction is a big win for both reading and writing funcs with 5 to 10 or more error handling conditions _(I do not write funcs that long, but I sure as heck have to read a lot of really long funcs. Case in point.)

A feature that other developers would adopt to shorten their funcs is a real win to me. If it does not make whitespace significant, of course.

[lainio]

@ijxy, thank you for your follow-up.

With optional blocks, ? turns Go into a whitespace-sensitive language. That is a very big price to pay for anything; I would consider it a breaking change since it can break existing (valid) code.

Breaking change of what, exactly? Can you provide an example of existing valid Go code that would break due to the ? proposal?

If you mean code written after the proposal is implemented, then yes, new syntax could introduce new potential pitfalls. But if you're referring to existing Go code today, I have tested the new compiler and migration tool and couldn't find any cases where it breaks existing valid programs.

The original proposal clearly states:

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.

This explicitly refers to Go programs written with (or after) the ? proposal—not existing Go code.

We can illustrate this with a simple example. Any whitespace-related issues introduced by ? follow this same general pattern.

Correct Version

func CopyFile(src, dst string) error {
	var err error
	r := os.Open(src) ? {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

Incorrect Version

func CopyFile(src, dst string) error {
	var err error
	r := os.Open(src) ?
	{
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

Now, we can assess how often such issues would actually occur.

I analyzed 1.5 million lines of Go code from major projects (Kubernetes, CockroachDB, Hugo, etc.) and found only 3 potential cases that resemble this pattern:

Real-World Examples

exp.mu.Lock()
{
     data = exp.data
}
exp.mu.Unlock()

sb.debugTracef("initialized stage builder for %s", opType)
{
     ...

p.EnterOuterAlt(localctx, 1)
{
     p.SetState(32)
     ...

Of course, we can compare Go’s whitespace sensitivity before and after ? with languages like Swift, Rust, and Zig. Surprisingly, none of these languages are entirely whitespace immune.

Since Go already uses {} blocks universally, the suggested optional block syntax is hardly problematic. In my view, we gain a lot while losing nothing.

[latzskim]

I would like to ask how long do you plan to keep this discussion open? It could take weeks or months, with people arguing about whether this is good or bad.

What are the next steps regarding error handling? What happens if this proposal is accepted or rejected?

I think each proposal should have an ETA or deadline so everyone is on the same page

[x86cloud]

r := SomeFunction() ? { return fmt.Errorf("something failed: %v", err) }
Compared with the above treatment, I prefer the following one.
r := someFuntion()?.mapErr(func(err error) error { return fmt.Errorf("event x caused error: %w", err) })

[b0123456789]

1.single line, with error
data:= DoSomething()? err orelse return err
data:= DoSomething()? err orelse { return err }

2.return new error
data:= DoSomething()? orelse return errers.New("new error")

3.multi line
data:= DoSomething()? orelse {
a:1
errmsg:=errers.New("new error")
return a,errmsg
}

[louiss0]

It seems like this proposal has gotten way out of hand. People seem to have many different ideas for how error handling should be handled. Even though nothing is going to change anytime soon this discussion is something that people are passionate about. I to also wanted a different keyword to. But that's not going to happen.

So far there are three main ideas regarding this proposal about what the ? operator should be:

1. The ? operator should only be used for error cases and revolve around early return.
2. The ? operator should be used for all zero values.
3. The ? operator should be used for error cases and revolve around goto

When it comes to idea number one it's name will be called the Error Capture operator.
The point of this operator is that whenever and error is returned from a function, with a value on the left and an error on the right, the user must be able to return it immediately or subvert it by using a block.

Immediate return.

    func doRequest() error {
	   doSomething()? 
   }

Error subversion.

    func doRequest() error {
	   doSomething()? err { return fmt.ErrorF("Something's wrong %w", err) } 
   }

Capturing the value on the left.

    func doRequest() error {
	   value := doSomething()? 
   }

When it comes to idea number two I will call this idea the Zero Value Operator. The point is that any value that is negative on the left side can be captured by this operator. It's an operator that will catch any negative value from any return values on the left most side.
When a function returns two values or when you check if a map has an ok value.

Map

v := m["k"]? {
    return fmt.Errorf("map key not found: %v", k)
}

Type assertion

s := i.(string)? {
    return fmt.Errorf("type is not a string:  %v", i)
}

Channels

v := <-c? {
    return fmt.Errorf("channel has been closed")
}

Function returning two values.

	value := doSomething() ? error { fmt.Errorf("Invalid %w" error)  }  

The third idea is based on the idea that the ? operator should be used with goto instead of defining a return type instead. It's still what I call the Error Capture Operator. But you don't write early returns instead you write. goto statements and tell the function what code to go to when an error is found. The error is exposed through an implicit variable.

  function doRequest() (string, error) {

	var error error;
	 
	doSomething()? goto catch;

	doSomethingElse()? goto catch;  
	  

	catch: 
		error = err
		goto end
	end:
		return "", error
	
	return "Value ", nil
  
  }

This idea can also apply to the second idea as well. This fourth idea would be called Zero Value Operator (GOTO).

function doSomething() error {

v := m["k"]? goto createErr

 createErr:
	 fmt.Errorf("map key not found")

}

Well it's up to you guys to vote on which one you'd prefer. Please reply to this post on which idea you want. I won't argue for one over the other. This idea is a strange one to me.

Vote!

• Error Capture Operator (Early Return)
• Zero Value Operator (Early Return)
• Error Capture Operator (GOTO)
• Zero Value Operator (GOTO)

[mikeschinkel]

It seems like this proposal has gotten way out of hand.

it is the nature of the beast, as the beast is currently configured. Maybe you could consider upvoting this if you think it would help reduce noise on future issues?

Well it's up to you guys to vote on which one you'd prefer. Please reply to this post on which idea you want. I won't argue for one over the other. This idea is a strange one to me.

Vote!

• Error Capture Operator (Early Return)
• Zero Value Operator (Early Return)
• Error Capture Operator (GOTO)
• Zero Value Operator (GOTO)

I think maybe either you mischaracterized two of them as the "Zero Value Operator" instead of an "On Fail Operator"

And respectfully, I think you are presenting this as a false quaternary. There is no technical reason that all four would not be able to coexist — or some subset of the four.

[tandr]

@ianlancetaylor Seems that most of the benefits would come from the simplest form

v := function()?

May I suggest to go small at the beginning, and just allow this simplest form? Once it is used here and there, one of the next versions may have some variations with more complex form if it would be even required, since classical if err != nil {...} covers it nicely.

[apparentlymart]

Hi @tandr,

The proposal author asked that we represent what you've suggested here by voting 👎 on #71460 (comment).

[tandr]

I did cast my vote, thank you. But the discussion is sort of going circles, and I am just suggesting "maybe lets go simple, and stop there for now, with reevaluation of it later" . Maybe put it under experimental features, see how it goes...

[apparentlymart]

Ian has also already retracted this proposal in #71460 (comment), FWIW.

[uhthomas]

I like the idea and general sentiment of reducing boilerplate, and the proposal makes sense to me. Though I can't help but feel a '?' is not very visible and the meaning not immediately obvious.

I'd prefer something more similar to the original try proposal. A new keyword like 'check' is immediately more visible and the intent is much clearer. Moving it from the end to the beginning is also better for readability. An optional block like in this proposal would also apply.

v, err := do()

v := check do()

v := check do() {
  return fmt.Errorf("some error: %w", err)
}

It would be nice to support error variable names other than 'err', and it does feel a bit magical for it to just appear. I wonder if it would be possible to adjust this to explicitly declare error variables such:

v := check do(); err {
  return fmt.Errorf("some error: %w", err)
}

I'd been to hear your thoughts. Sorry if this has already been proposed or discussed.