Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
carlmjohnson opened this issue Jul 17, 2019 · 16 comments

Comments

@carlmjohnson
Copy link
Contributor

commented Jul 17, 2019

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)
	}
}
  1. 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.

@gopherbot gopherbot added this to the Proposal milestone Jul 17, 2019

@gopherbot gopherbot added the Proposal label Jul 17, 2019

@3timeslazy

This comment has been minimized.

Copy link

commented Jul 17, 2019

Second point looks good

@ianlancetaylor ianlancetaylor changed the title Proposal: simplify error handling with ? and ... proposal: Go 2: simplify error handling with ? and ... Jul 17, 2019

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2019

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

@carlmjohnson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 17, 2019

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

This comment has been minimized.

Copy link

commented Jul 17, 2019

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

This comment has been minimized.

Copy link

commented Jul 17, 2019

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.

@carlmjohnson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 17, 2019

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

This comment has been minimized.

Copy link

commented Jul 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2019

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

@ilango100

This comment has been minimized.

Copy link

commented Jul 18, 2019

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
@carlmjohnson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2019

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.

@ilango100

This comment has been minimized.

Copy link

commented Jul 18, 2019

A lot of times, it is needed to return whatever values are set when some error occurs. Just because an error occurs doesn't mean you should always return zero values for other return parameters.

The calling code may inspect this error and take necessary action using the "intermediate" result.
The best example would be io.Reader, when an EOF occurs. Underlying implementation may return read bytes and also an error.
So using named values solves both these problems (zero values or intermediate values).

I wonder why it cannot be used in most functions.

@carlmjohnson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2019

io.Reader/Writer is the exception that proves the rule. Almost nothing else can return both an error and a result. It's pretty much one or other. IO is different because it is possible to do a partial read/write and still get meaningful results, but there's no such thing as half an HTTP response header or half a decompressed file.

@qaisjp

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2019

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 "variadic return"

@mvndaai

This comment has been minimized.

Copy link

commented Jul 19, 2019

@carlmjohnson I love the return ..., err it might be worth making a separate proposal just for it.

@DongchengWang

This comment has been minimized.

Copy link

commented Jul 20, 2019

The if statement is like

if <bool> {
        ...
}

Looks like err? returns a bool. I think using ? to replace !=nil doesn't solve the error handling problem at all.

@dongweigogo

This comment has been minimized.

Copy link

commented Aug 19, 2019

why not just
r := os.Open(src)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.