proposal: Go 2: simplify error handling with ? and ...

[earthboundkid]

The try proposal #32437 was recently declined. This is an alternate proposal to achieve the goal of simplifying error handling. It has two parts:

1. Make EXPRESSION? return a bool, true if the expression is a non-blank value, false is the expression equals the blank value. So, for interface types, it would be equivalent to EXPRESSION != nil.

Usage:

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

	w, err := os.Create(dst)
	if err? {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if _, err := io.Copy(w, r); err? {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if err := w.Close(); err? {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
}

2. Make return ..., EXPRESSION fill in as many blank values as needed to fulfill the signature of the function.

Usage:

return ..., err

return ..., fmt.Errorf("something went wrong: %v")

Rationale:

Given the design goals for improving error handling, it is difficult to imagine any proposal that doesn't end up being non-orthogonal with if and defer. This makes it simpler for text editors to insert the correct boilerplate for an early return automatically, and it saves a few characters for programmers who type the whole thing out manually.

[3timeslazy]

Second point looks good

[ianlancetaylor]

The ? part of this proposal looks essentially the same as #32845.

[earthboundkid]

Didn't see that issue. I've seen proposals to allow return _, err (although I can't find an issue ATM), but not return .... The difference between return _ and return ... is that ... would return as many values as necessary, not just one, so it could be used in any function with an error return.

[hchargois]

I was going to open an issue to propose the same thing as the 2nd point.

I see two main benefits of this:

1. It is a pain to have to write the zero values explicitly while they don't carry any meaning anyway because it is an error return
2. If you change the signature of the function, you often have to change multiple lines because you have multiple error returns

This proposal solves both issues beautifully.

Compare

func before() (bool, string, MyStruct, error) {
    return false, "", MyStruct{}, errors.New("error")
}

func after() (bool, string, MyStruct, error) {
    return ..., errors.New("error")
}

Let's throw the "ellipsis" keyword here so that this issue can be found more easily, because I think that's what "..." is commonly called.

Also, if #21291 passes, this could be used to return explicitly "all-zeros" with return ...

[ziflex]

Hey, thanks for the proposal.
But I'm having issues with understanding what value it brings.
Both options, conceptually do not bring any solutions to the problem. They just save few characters that you have to type. It feels more like a workaround than a solid solution.

[earthboundkid]

They just save few characters that you have to type.

Yes, I have come to the conclusion that apart from try(), saving a few characters is all that is possible, because all the other proposals end up reinventing if and defer with non-orthogonally different semantics.

[ziflex]

My gut feeling says that maybe it’s too early to solve this “problem” with the current state of the language.
Probably, we need new language constructions for a better solution. (Pattern matching, for example)
I would encourage the community to put it on hold and focus on other parts of the language.

[OneOfOne]

IMO those are 2 different proposals, for example I really like the ..., err part but absolutely hate the first.

[ilango100]

Isn't named return values an alternate solution for ellipsis?

func aFunction() (a int, b string, c bool, err error) {
  if er := someCall(); er != nil {
    // Should be aware not to shadow return params
    err = fmt.Errorf("Error: %v", er)
    return
  }

  ...
}

We don't have to explicitly return the zero values each time this way. They are auto populated at function start.
If the naked return affects the readability, we can even use

return a, b, c, err

[earthboundkid]

Named values may have been set and not zero. Depending on the function, that matters. Also they can't be used in all (or even most?) functions, which makes it inappropriate for an editor macro.