From the very little Go I’ve written, I gotta say that the explicit if err != nil error handling struck me as something pretty darn good even if a bit verbose. And in my experience outside Go, just knowing its outlook on error handling has nudged me towards writing more satisfying error handling code, too: https://riki.house/programming/blog/try-is-not-the-only-option

I also regularly write C++ code which does error handling in this way and do not find it particularly revolting. (Though most C++ I write is very game devy, where an error usually results in a crash, or is logged and the game keeps on chugging along.)

I can see why people would not share the same opinion though. Perhaps I’m just slowly becoming a boomer.

My hope is this doesn’t go through, it’s merely a syntactic sugar that unfortunately introduces more questions than it answers. The comments bring up a lot of real issues with zero-or-not value, automatic err variable declaration, etc.

I can think of others edge cases too, like functions that return a concrete type that happen to implement the error interface, or returning the error at different positions in the tuple. These questions shouldn’t be ignored, semantic concerns should trump syntax.

The real problem is that error handling is not statically enforced. If that won’t change I see no reason to reduce boilerplate by one line.

I’m usually very critical of error handling proposals, but I really like this one. It keeps the spirit of current error handling instead of trying to replace it. It does look a bit weird on first sight but I easily can imagine getting used to it.

I’m not a big fan of the automatic err variable declaration though.

Edit: reading more into it, I don’t like the automatic return when ? is not followed by a block.

func Run() error {
	Start() ? // returns error from Start if not nil
	Wait() ?  // returns error from Wait if not nil
	return nil
}

This example is too far from current Go idioms, visually (without reading it) I thought it was an interface declaration. I wish they would keep explicit err return like this:

func Run() error {
	Start() ? {
		return err
	}
	Wait() ? {
		return err
	}
	return nil
}

Edit 2: I don’t like it anymore.

I really dislike this. It seems to solve a non-issue in a very un-Go-like way.

This is a very confusing proposal and problem. When I write go, I’m more concerned I have to rely on checked casts just to know if the err I have is what I think it is and I can never guarantee I have an exhaustive set of branches for every possible (possibly even nested and wrapped) error. I don’t see how sugaring over:

err := something()
if err != nil {
    ...
}

really solves the biggest problem I see and I can’t imagine if err != nil is a struggle for many.

This can’t land fast enough. if err != nil reads simple on its face, but has always felt extremely clunky and error prone, and comes with an air of “well simply don’t forget to check for nil here!” It’s one of many reasons I’ve never enjoyed writing Go and have joked that it’s a world-class ecosystem and toolchain lacking only a decent language.

Changing all return signatures of the Go ecosystem would be a fatally breaking change, so at least reducing the boilerplate to make the existing signatures more ergonomic (and maybe a bit less error prone) feels like a huge positive to me.

OK, interesting. I was gonna dismiss this as one of the thousand “let’s put a new syntax on an idea that has been suggested many times” proposals, but this one is by Ian Lance Taylor, a member of the Go Team.

It would be convenient for functions that return (result, err) pairs if ? with no block returned zero for the result and passed through the err.

This proposal mentions a separate one to allow writing return ..., err instead of return result, err, but I don’t see any examples suggesting that’s going to kick in automatically for ? with no block. The case for adding that behavior is just this occurs a lot and this would make it more concise. I imagine the case against has to do with complexity or the potential for mistakes.

If the argument is mostly about implementation difficulty, I hope it’d be considered for addition later if it doesn’t make the initial implementation.

I guess this is fine? It doesn’t really do much.

This is the year of linux sane error handling in the desktop go.