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