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.

[tim-upguard]

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

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

[mukunda-]

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

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

[JetSetIlly]

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

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

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

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

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

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

to

r := foo() ?

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

[alex-klimov]

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

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

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

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

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

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

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

[soypat]

I appreciate the effort put into this proposal. Kudos to the Go team.

I'd like to note that the threads being opened below are hard to follow since there is a lot of noise between the voting sections. I'd also like to note that the sub-proposals lack examples of what is meant, leaving a lot of room for misunderstanding of the proposal. Not everyone is familiar with terms like "implicit declaration". Cold hard code logic should be easily understood by everyone.

Again, thank you for the proposal, I was not ready to come around to changing the way we handle errors in Go but something clicked with me with this proposal (though maybe not the entirety of it).

Edit: consider using emoji bullet point list to specify voting schema. It might also help to avoid the thumbs down emoji to segment the votes away from the haters. i.e:

• 🎉 Prefer thing A
• 🚀 Prefer thing B

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

[JetSetIlly]

Yes. I worry about that too.

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

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

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

Which would become

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

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

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

[prologic]

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

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

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

[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

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

[ianlancetaylor]

Sorry about the link failure, I blame GitHub. I meant the comment by @rdpn earlier on this thread, though there are others that also show the issue I'm concerned about.

I think the definition of "there is an error" is fairly clear, and I think everybody would agree as to whether or not there is an error. I think the definition of "the operation failed" is a collection of special cases, and I do not think think that everybody would agree as to whether the operation failed. You suggested that if the last value if the zero value of its type then the operation failed, but I see no particular reason to think that that is a general and well-understood rule.

[mikeschinkel]

@ianlancetaylor — Reconsidered where it would have most value, I realized that (by my estimates) 90+% of the value — ignoring the error case — would be for type assertions and map element access. Then another ~5% would be functions that return more than one (1) value, the latter being a bool ok value.

So by this revision <expr> ? { ... } could trigger the block when:

1. err!=nil for w,err:= getWidgetWithErr(),
2. ok==false for w,ok := data.(*Widget),
3. ok==false for w,ok := widgets[key], and
4. ok==false for w,ok := getWidgetWithBool().

I showed the assignments as the work today, not as they would work per the proposal so that you would see what getWidgetWithBool() returns.

With that revision — removing the general zero pattern from consideration — would you still think people would disagree on a claim that each of these is a failure?

1. An error generated,
2. A failed type assertion,
3. A failed map element access, and
4. A failed call to retrieve a value?

[ianlancetaylor]

You still have a list of special cases. People have to remember "is this one of the cases that is handled by ?"? For example, you left out v, ok := <-c, presumably because "failure" isn't a good way to describe that case.

It's not too hard to remember a single special case. It gets harder to remember more special cases.

And all of these cases happen much less frequently than err != nil, so I don't see the benefit as being worth the cost.

[mikeschinkel]

@ianlancetaylor —

"presumably because "failure" isn't a good way to describe that case."

No, I left it out because I did not think of it when I wrote the list.

[rdpn]

In brief:

var A T 
A ? {
    // In this block A value is
    // 0 for  numeric types
    // false for the boolean type
    // "" for strings type
    // nil for pointers / interfaces

    // A value doesn't need to be retrieved 
}

Not orthogonal to:

err ? {
    // In this block err != nil

    // err value must be retrieved by some mechanisms
}

Plus,

var A T 
A ? // what do we return ? "A is zero" ? feels weird...

vs

err ? // returns error

The '?' operator is interesting in itself because of the ability to push the error scope on the right and with the magnificent optional block it seems possible to handle all 'zero' + err !=nil cases in an effective manner.

But to conserve the the effectiveness and expressiveness of the Go and avoid any kind of confusion in writing or reading Go, @ianlancetaylor choose to restrain the '?' proposal to only and only, the error type. Even if the ..., ok := pattern looks like error handling very often.

This is pragmatic, by far err != nil is predominant, and maybe the '?' usage could be extended later.
Thank you @ianlancetaylor for bringing such nice discussion :-).

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

[flibustenet]

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

SomeFunction() ? err {
	return err
}

What about a reduced proposal for just that ?
I mean explicit err and no naked ? to begin

• It remove a little boilerplate
• It remove if err != nil from the happy path
• It's still explicit
• It doesn't encourage to don't annotate

It let us improve it later to allow ? alone.

[ianlancetaylor]

In the common case of code like

    SomeFunction() ? err {
        return fmt.Errorf("error: %v", err)
    }

there is no reason to have a variable err that is scoped to the entire function. Outside of the block it will always be nil. In general wanting the error variable to have full function scope rather than block scope is a much less common case.

[mikeschinkel]

@ianlancetaylor — 

"there is no reason to have a variable err that is scoped to the entire function."

There is a reason, you are just choosing to not acknowledge it. I give up. 😞

[ianlancetaylor]

OK, fair enough, there is a very uncommon reason.

[ianlancetaylor]

Wait, I explicitly said "in the common case...there is no reason." I think that is accurate.

[mikeschinkel]

@ianlancetaylor — 

It is in IMO unfortunately uncommon, because it is a pattern that works brilliantly. I hypothesize more people don't use it because of the decades long indoctrination against goto where the key argument against it ironically no longer applies, i.e. jumping across subroutines.

For every codebase of mine it is very common. Every function that returns an error uses it, which is why I say that "fixing" error handling to only support local scope really nerfs this pattern that otherwise works so well. I won't be able to easily refactor to use it without lots of boilerplate, and I won't be able to use it moving forward without lots of boilerplate.

That is why I was begging you to please at least support function scope as an option. As an option others would not have to use it, but I would still like the option to continue to do so. It would be as simple as allowing this:

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

In addition to your preferred approach:

SomeFunction() ? err {
  return fmt.Errorf("error: %v", err)
 }

And that is the last I will say on this thread. No need to reply, I just hope you don't decide to nerf the pattern that I have found to be so incredibly useful.

[sbiemont]

OK, this is a very interesting post, but it lacks explicit declarations: all returned values should be specified.

Here is a step-by-step example with explicit declarations.

First, remove err != nil and use ? like you suggested (which results in a similar behavior to using err != nil).
It only saves a few characters.

func whatever() (*int, MyStruct, error) {
  err1 := getError() ? {
    return nil, MyStruct{}, err1 // return err1
  }
  i, err2 := getIntAndError() ? {
    return nil, MyStruct{}, err2 // return err2
  }
  j, err3 := getIntAndError() ? {
    return nil, MyStruct{}, fmt.Errorf("wrap: %w", err3) // return wrapped err3
  }

  return &i, MyStruct{Foo: j}, nil
}

Then, same example, without the return blocks for a more compact writing: ? should accept all return values and act like it.

func whatever() (*int, MyStruct, error) {
  err1 := getError() ? nil, MyStruct{}, err1 // return err1
  i, err2 := getIntAndError() ? nil, MyStruct{}, err2 // return err2
  j, err3 := getIntAndError() ? nil, MyStruct{}, fmt.Errorf("wrap: %w", err3) // return wrapped err3

  return &i, MyStruct{Foo: j}, nil
}

At last, same example but with a new optional helper (like ? (err error) { .. } or catch ? or catch or what you can think of).
It could act like a goto, catch or rescue (which goal is to explicit the returned values before leaving the method).

Note: all errors should be declared and used but for err2 ?, it could be explicitely declared and implicitely used at the same time.

Mentally replace the content of the helper when you read a ? symbol.

func whatever() (*int, MyStruct, error) {
  ? (err error) { // declaration of some kind of a "catch" method
    return nil, MyStruct{}, err
  }

  getError() ? // catch & return err
  i, err2 ? := getIntAndError() // catch & return err2 (err2 is declared and used only here)
  j, err3 := getIntAndError() ? fmt.Errorf("wrap: %w", err3) // direct wrap err3, catch & return wrapped err3
  k, err4 := getIntAndError() ? {
    return fmt.Errorf("with block: %w", err4) // wrap err4 in a block, catch & return wrapped err4
  }

  return &i, MyStruct{Foo: j, Bar: k}, nil
}

To sum up

err ? is a pretty solution that can reduce the error verbosity but it has to be used with other mecanisms to be more explicit.

I took a lot of shortuts, so now, it is your turn to find a realistic compliant solution !

// optional use of a "catch" method to fill returned values
? (err error) {
  return nil, MyStruct{}, err
}

// use of `?` at declaration
i, err ? := getIntAndError()

// use with an additional instruction or block
i, err := getIntAndError() ? panic(err)

// declare and use
i, err := getIntAndError()
err ? // like: return err
err ? fmt.Errorf("wrap: %w", err) //  return wrapped err
err ? { // or with block
  panic(err)
}

// should not compile due to lack of error declaration
i, _ := getIntAndError() ?

[mfridman]

I liked the slide Rob had in his 2015 talk "Simplicity is Complicated".

Go is different.

Go does not try to be like the other languages.

Go does not compete.

As of Go 1, the language is fixed.

Many newcomers to Go ask for features from languages they know.
But those features do not belong in Go--and the language is fixed.

Adding features to Go would not make it better, just bigger.

That would make Go less interesting by being less different.

The "boilerplate" you're referring to is a core feature of Go. It's explicit, simple, and somewhat verbose. And that's okay! We don't need "new syntax partly inspired by language X or Y". I use "we" to refer to those who have been writing Go for more than weekend projects - those with production experience or substantial oss contributions.

While you've reduced it to a one-liner, I've come to really appreciate the explicit nature of error handling (forcing developers to think about how to handle errors at each call site). The if err != nil {} idiom is quickly learned and accepted by project newcomers, as an example.

This proposal has limited merit - it adds another way to do things and makes code harder to read (ironically). I really hope Google is not on a path to grow the language at all costs, as that would undermine what makes Go lovable for its long-term users.

Let's keep Go simple and boring.

[akaita]

I absolutely agree with you.

This proposal is going directly against the philosophy Go is built upon.

It's just slightly increasing complexity and reducing readability, to simply not solve any problem.

[iambpn]

Here is my 2 word on this proposal, As a user and a fan of GO, I was attracted and fell in love with the simplicity of the GO.
And, Now we are trying to convolute the language by adding these features. Yes current error handling is verbose, but it's more simple and easy to understand than proposed solutions.

I think we do not need to update the error handling, and it is fine as it is.

[iemelyanov]

I'm a Go user with almost 10 years of experience, and I've never thought that error handling is a problem. It's simple—let's keep the language simple and not allow doing the same thing in many different ways.

I think there are many other areas where Go can be improved, but at least not in its syntax and error handling.

[lalaithion]

My main issue with this proposal is that it tries to make returning an unwrapped error easier, and only slightly improves the ergonomics of returning wrapped errors. I would be much more interested in a proposal which focuses on making wrapping errors easier.

[sjc5]

I took a look through the converted std lib with my best attempt at an open mind.

I found the converted code to be substantially less clear overall.

Lack of leading if and explicit err means I need to look for ? too deep into a line of code to understand what is going on. This is a weak analogy, but it almost becomes a right-to-left language instead of left-to-right.

I also really dislike the new ambiguity around the number of returned values from functions.

For context, I am a big fan of Go generics and am very happy to have them in the language, so this is not coming from a perspective of being against all new additions.

[louiss0]

I think it's okay to just do this.

      value,  err  ?=  sumFunc()  {
                 return err
      }

The block will execute when the error is not nil.

The ?= syntax tells the compiler that this is a special assignment.

I don't mind := someFunc ? { } but this operator is shorter.
I think the user should be forced to do something with the block.
If there is a return statement the function simply returns.
If not the code goes through.

My idea doesn't extend to nil in the second parameter but any value that is nil or empty.
If value is empty the block will activate; If err is empty then the block will activate.
Since the block is just a shorthand it will have access to the outer scope.

Another idea is to just make a special block

        catch value,  err  :=  sumFunc()  {
                     return err
      }

The catch keyword is to indicate whether an empty value or a nil is caught in either of the values. Think of it as a shorthand. It means that the variables created after the catch block still exist in the outer scope. The catch means catch any nil values and activate this block if you do.

[apparentlymart]

Hi @louiss0,

I believe ideas substantially similar to both of these have already been discussed in other threads above, but I don't blame you for not finding them because GitHub Discussions hides most of the threads once there are too many, and also hides individual comments within certain threads once there are too many, and so it's simply impossible to review the entire discussion at this point. 😖

However, that aside I think the main thing to know is that Ian is planning to close this discussion soon anyway, and so it seems that nothing is going to change as a result of this proposal, and so there's still room for others to make alternative proposals separately from this discussion if they want to.

[latzskim]

I'm glad that the Go team is addressing error handling in Go and striving for improvement. I like the current error handling in Go, but having worked on many projects and teams where people mostly came from other languages like Java or PHP, error handling in Go was terrible because there was if err != nil { return err } everywhere.

Could you simplify it like this?

1. No err declaration when you don’t need to use the error:

val := somFunction() ? {
 return errors.New("some function failed, no details")
}

2. Declare err (you can use different name, just like any other variable) when you need to use the error:

val := someFunction() ? err {
return fmt.Errorf("some function error: %w", err)
}

3. Return the error to the caller without handling it:

val := someFunction() ?

[yurivish]

One possible downside is that it might be easy to introduce mistakes using the second variant if there is an err variable in a parent scope.

Correct:

val := someFunction() ? err {
  return fmt.Errorf("some function error: %w", err)
}

Incorrect (but would compile and run):

val := someFunction() ? {
  return fmt.Errorf("some function error: %w", err) // uses an unintended err variable
}

[abenz1267]

Time to think outside of the box!

For simply returning err:

value, err? := something() // return err
err?, value := something() // ... would obv. work as well! position doesn't matter, easy to parse

For handling if err != nil

value, err := something()
err? {
  // do something with err
}

or inline (i hate this)

value, err ? { return fmt.Errorf(...) } := something()

Or if ? is too bad for readability:

value, guard err := something() // `guard` as new keyword

value, err := something()
guard err {
 // do something with err
}

[doggedOwl]

this solves nothing for redability.

[dmitryuck]

One more suggestion without ? mark where err is not required for declare

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

in case if we want to skip error, which now equal r, _ := SomeFunction()

r := SomeFunction()

it's kind of we just moved err variable from a long syntax and mixed with short syntax, kind of successor

// long syntax
r, err := foo()
if err != nil {
    return err
}

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

Become

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

[dmitryuck]

no additional ? operator needs to be added to the language, which keep it simple

[ianlancetaylor]

I think we need some indication of the control flow. We shouldn't just infer it with no syntactic element at all.

[jmcmullan]

I almost like your proposal.

// err is ignored
r, _ := foo() 

// err is handled explicitly
r, err := foo()
if err != nil {
  ...
}

// err is handled _implicitly_
r, ? := foo()

// err is handled _by name_ to permit auto-wrapping
func bar() (err error) {
  defer func () { if err != nil { err = fmt.Errorf("bar %w", err) } } ()
  
  ...
  // Implicit if err != nil { return err }
  r, err? := foo()
  
  // Implicit if fullerr != nil { return fullerr } (which would bypass wrapping)
  r, fullerror ?:= qux()

[VaskoBozhurski]

Part of the appeal of Golang for me is the simplicity and verbosity of the control flow. This change while making writing slightly more convenient (less symbols to type), makes the language more complex and readability harder. If I want error handling where an error can bubble up seamlessly up the call stack, I could just go with a language that supports exceptions. I really don't see why people want to turn Golang into a language it isn't or rather wasn't.

[mukunda-]

I think the proposal actually advocates for more "Go-like" style, since it makes it more convenient to use the usual error patterns. I find it most tedious with I/O work. Take these two examples:

...
f, err := open(file)
if err != nil {
   return err
}
defer f.Close()

if err = binwrite(f, signature); err != nil {
   return err
}
if err = binwrite(f, header); err != nil {
   return err
}
if err = binwrite(f, zeroSegment); err != nil {
   return err
}

for _, s := range segments {
   if err = binwrite(f, s); err != nil {
      return err
   }
}

if err = binwrite(f, footer); err != nil {
   return err
}

Half of those errors would never happen unless your hard drive is full. In that case, you've got bigger problems. I prefer not thinking about that in my code.

...
f, err := open(file)?
defer f.Close()

binwrite(f, signature)?
binwrite(f, header)?
binwrite(f, zeroSegment)?

for _, s := range segments {
   binwrite(f, s)?
}

binwrite(f, footer)?

Given that the first version looks hideous (opinion?), I use panics in today's Go to get something more like the second. Using panics rigorously is not Go-like, but I find the code structure a lot more appealing.

I don't like Go because it's "simple". I don't think Go is simple. A stranger to Go is going to get confused up and down about many concepts (struct implementation and pointer receivers is nothing like most other languages) without some practice. BUT, it has terrific tooling, testing, cross-platform runtime, dependency management, etc. I use Go because it's EASY to be productive with it.

Concepts like the primitive error handling I do not like. Hence, I'd welcome the ? shortcut.

[doggedOwl]

Try reading the proposal again. This is nothing like exceptions and does not bubble up anything more than what is trying to substitute.
For reading, this is better according to many people, however if you prefer the old style it's still available and you can use it.

[ugorji]

I think this is what we're solving for. We should have folks vote on this small part. And then find a solution that solves for at least this. I've been using go since it was pre-1.0, and I still hate the prevalence of if err != nil { return } taking 2 or 3 extra lines all over the place, and impacting readability a lot. Please @ianlancetaylor - there's value in capturing the sentiments across the responses and analyzing them, instead of doing a "go/no-go" based on the loudness of responses or blind thumbs-up/down.

It's clear from every annual survey that error handling is a big issue. I almost fall back in love writing java code, because it starts feeling succinct. Please - let's do this.

[bigwhite]

I like mukunda's idea that trying to use go-like styles as much as possible and his grammar suggestions. we should just solve the most common error handling boilerplate code.

e.g.

f, err := open(file)
if err != nil {
   return err
}

if err = binwrite(f, signature); err != nil {
   return err
}

And If we cannot be sure, the optional block may not be considered in this time. Just keep them in the current style, which also avoids many implicit declaration and variable shadow issues.

[louiss0]

I like @dmitryuck 's idea. It's good but I think it should require a new keyword.

Instead of this.

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

We need this.

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

People need to know that the block that is being used is special. When the block returns that means the function returns too. The problem with your proposal is that you talked about there being an implicit variable with a specific name. It's best to just let the variable be the name the developer chooses.