proposal: Go 2: one line error handling with EReturn function

[olambo]

Introduction

I've read through a lot of the error handling proposals. I think the ones being considered are not simple. This proposal is for simple cases of assignment to an error. I do not propose any sort of global error handling. I do not propose any sort of chaining. I do not propose the mechanism proposed be provided to assignment to any variable.

Proposal

Any error function with the signature: func(error, string) error can be used in place of an assignment to a error variable. An error function is provided in the "fmt" package that will provide simple error handling. This error function is called EReturn.

Locally any function with the signature func(error, string) error can be used directly if it has the name eReturn Otherwise the function can be assigned to a variable called eReturn. Variable assignment could be used to assign different functions whether local or from a different package. It is my view that it would be unusual to have to more than one local error handler because the string parameter can be used to differenticate between use cases.

In use, the error is implicitly provided to the error function. Some examples may make the proposal more clear.

Assuming the package "fmt" is modified to include the following error function. Because it has the right signature and name, it can be directly used for many use simple use cases.

package fmt

// return the current error for a blank string, otherwise wrap the error
func EReturn(e error, errstr string) error {
	if errstr == "" {
		return e
	}
	return fmt.Errorf(errstr+": %w", e)
}

The proposed syntax with an error function in assignment position.

// 1. passes through the error from strFunc
str, fmt.EReturn("") := strFunc("something")

// 2. wraps some new infomation around the error from os.Open
file, fmt.EReturn("missing today's text") := os.Open("today.txt")

return file, nil

Both of the above case are syntactic sugar that the compiler can expand. For instance 2. is expanded to:

file, err := os.Open("today.txt")
if err != nil {
	return nil, fmt.EReturn(err, "missing today's text")
}

Locally the errstr passed through to the function may provide enough information to differentiate between cases. For example

func localEx(loc string) {
	const special = "I'm special"
	eReturn := func(e error, errstr string) error {
		errprefix := fmt.Sprintf("loc: %v ", loc)
		if errstr == special {
			// do some special processing
			return fmt.Errorf(errprefix + "special error " + errstr +": %w", e)
		}
		return fmt.Errorf(errprefix + errstr +": %w", e)
	}

	sp, eReturn(special) := specialFunc()
	sns, eReturn("not special") := notSpecialFunc()
    // more calls
}

Discuss

Possibly, EContinue, EBreak could be proposed to be used in loops. Possibly ELog could be used to continue

Template - Language change

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  this is an interesting question
• What other languages do you have experience with?
  Scala, Java, Some others
• Would this change make Go easier or harder to learn, and why?
  it's an extra concept to learn
• Has this idea, or one like it, been proposed before?
  I haven't looked at all the ideas in idea space
• Who does this proposal help, and why?
  some of those concerned that simple error handling is too verbose
• What is the proposed change?
  • Please describe as precisely as possible the change to the language.
    please see above proposal
  • What would change in the language spec?
    please see above proposal
  • Please also describe the change informally, as in a class teaching Go.
    not my expertise
• Is this change backward compatible?
  yes
• Show example code before and after the change.
  see above proposal
• What is the cost of this proposal? (Every language change has a cost).
  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    vet, gopls, gofmt
  • What is the compile time cost?
    I'm not a compiler writer
  • What is the run time cost?
    the proposal is syntactic sugar
• How would the language spec change?
  an error function with specific name and signature
• Orthogonality: how does this change interact or overlap with existing features?
  no interaction, I think
• Does this affect error handling?
  yes
• If so, how does this differ from previous error handling proposals?
  there are a huge number of proposals, but I haven't read an equivalent
• Is this about generics?
  no

[seankhliao]

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

[seankhliao]

see #32473 for a proposal on assigning to a handler functions

As I understand the limitation on naming means you can only have a single handler per package?

[olambo]

@seankhliao
you can have many

[deanveloper]

Once this is done you can assign any error function to a variable of name eReturn. That way you can swap between error functions. (I've updated the proposal to make this more explicit).

I am really not a fan of this being the way to have multiple error handlers, especially because there is often going to be multiple handlers in a single package. In particular, it is clunky (you have to assign your error handler before you use it) and it isn't safe to use across multiple goroutines.

Are we talking about a local variable eReturn or global? I'm a bit confused here because the proposal mostly talks about a global eReturn

[olambo]

@deanveloper I don't tend to use global variables.

[deanveloper]

Yes sorry for the confusion, it was because the proposal typically defines a global eReturn function, so I was thinking you had meant using a global eReturn variable as well. My bad.

Still unsure what I think about it.

[olambo]

@deanveloper Thank you for having the politeness of giving me your opinion. Based on what you said, I rewrote my proposal to make it as clear as possible. I believe you said in another thread that you like explicit "return " statements and I can completely understand this.

[deanveloper]

Yeah I had said that before. I’m not sure if I still stand by that statement though. I’d rather use a solution that keeps explicit returns, but I’m getting more flexible to those that don’t have them.