proposal: Go2: error handling shortening

[chad-bekmezian-snap]

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  intermediate

• What other languages do you have experience with?
  Java, C#, Javascript, PHP, Python, C++.

• Would this change make Go easier or harder to learn, and why?
  Only slightly harder as it is largely just syntactic sugar and is fairly easy to read and recognize.

• Has this idea, or one like it, been proposed before?
  There have been many error handling proposals, so I'm sure there have been similar ones, but none quite like this one I believe.

  • If so, how does this proposal differ?
    Many of the other proposals either require the addition of a keyword/identifier in Go (which has backwards compatibility issues),
    attempt to add subtle syntax changes (such as "?") to change the flow or behavior of a program, or behave very differently than
    typical Go behavior. This proposal attempts to avoid all of those issues.

• Who does this proposal help, and why?
  Every Go user. It helps cut down on ugly bloated code, and makes for a clear and concise line of error handling.

• What is the proposed change?
  I propose that the compiler generate the commonly used err := Func(); err != nil

  • Please describe as precisely as possible the change to the language.
    Compilers need to be changed to recognize an if following an assignment operator and generate the same compiled code as it
    would in the case of if err := Func(); err != nil

  • What would change in the language spec?
    This behavior would be documented under if statements

  • Please also describe the change informally, as in a class teaching Go.
    Currently if one would like to handle an error in the case of a method or function that returns multiple values, a developer is
    generally required to write five lines of code: one for variable assignment, on for an if statement checking if the error is nil, one for
    the opening curly brace, one for the body of the if statement, one for the closing curly brace. This proposal would, in many cases,
    mean those five lines are collapsed into one.

• Is this change backward compatible?
  I believe so.

  • Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.

• Show example code before and after the change.
  Before change

func SaveFavoriteColor(personID int, color string) (Person, error) {
  person, err := PersonByID(id)
   if err != nil {
      return err
   }

  person.FavoriteColor = color
  if err :=  SavePerson(person); err != nil {
    return err
  }
  // Trigger some event...
  return person, nil
}

After change

func SaveFavoriteColor(personID int, color string) (Person, error) {
  person := if PersonByID(id); return
  person.FavoriteColor = color
  if SavePerson(person); return
  // Trigger some event...
  return person, nil
}

• What is the cost of this proposal? (Every language change has a cost).
  Work will have to be done on the compiler. I'm not familiar with the process, but I'm should it would not be particularly easy.

  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    All of them.

  • What is the compile time cost?
    Should be negligible.

  • What is the run time cost?
    No greater than a classic if err != nil check is today.

• How would the language spec change?
  Added example and explanation under if statements.

• Orthogonality: how does this change interact or overlap with existing features?
  Totally orthogonal.

• Is the goal of this change a performance improvement?
  No

  • If so, what quantifiable improvement should we expect?
  • How would we measure it?

• Does this affect error handling?
  Yes

  • If so, how does this differ from previous error handling proposals?
    Does not introduce any new keywords and reads very similarly to what we have today.

• Is this about generics?
  No

  • If so, how does this relate to the accepted design
    and other generics proposals?

[chad-bekmezian-snap]

@gopherbot add error-handling

[chad-bekmezian-snap]

@gopherbot add v2

[mohamedattahri]

person := if PersonByID(id); return

Hard to understand what this statement does. Saves a couple of keystrokes, but takes all the readability away with it in exchange. Not a fair deal IMO.

[Sniperq2]

May be this is what you are looking for? https://go.dev/blog/errors-are-values

[ianlancetaylor]

Your "before change" code doesn't look right, because it has return err but the function actually has two results. And then that carries over to the "after change" code: what should happen if the function has multiple results?

Does this proposal have any way to handle return nil, fmt.Errorf("saw an error: %v", err) ?

[neurlang]

better inplement return return

func errorHandler[T any](p T, err error) (T) (T, error) {
   if err != nil {
      return return nil, err
   }
  return p
}


func SaveFavoriteColor(personID int, color string) (Person, error) {
  person := errorHandler(PersonByID(id))
  person.FavoriteColor = color
  errorHandler(person, SavePerson(person))
    // Trigger some event...
  return person, nil
}

[gophun]

Anyone who proposes a change to error handling should demonstrate the proposal's benefits based on code like this:

person, err := PersonByID(id)
if err != nil {
	return fmt.Errorf("could not find person by ID %d: %w", id, err)
}

not on code like this:

person, err := PersonByID(id)
if err != nil {
	return err
}

as the latter is a bad practice that we certainly do not aim to make easier.

[chad-bekmezian-snap]

I must admit, I don't particularly like my proposal myself. My primary hope was actually to maybe get people to start thinking/talking about how we could utilize existing keywords to solve this issue in a meaningful way, rather than adding a new one.

[mohamedattahri]

@chad-bekmezian-snap – How would you define the issue?

Considering that in Go, errors are values just like any other, why would we want to create a special syntax to deal with them?