proposal: Go 2: use symbol or function call in assignment for error handling

[ctlod]

The final form of this proposal can be found further down in #33150 (comment)

---

Use ! (or some other symbol) as special symbol in assignment for error handling

My issues with a built-in function try as proposed is 4 fold.

1. Excess of function calls all over the place.
2. Allows chaining, exasperating the above point.
3. defers should not be required to decorate an error.
4. I don't use go full time, and the example code I've seen just felt messy.

func MyFunc() (error) {
  f, err := os.Open(filename)
  if err != nil {
    return …, err  // zero values for other results, if any
  }
}

can be simplified to

func MyFunc() (error) {
  f, ! := os.Open(filename)
}

This resembles the _ key symbol, but is only applicable to errors.

HandlerFunctions: func myHandler([...]) error
Takes at least 1 argument compatible with the type of error returned.

eg:

func myHandler(err error, x string) error {
  return fmt.Errorf("copy %s : %v", x, err)
}

And used as so:

func MyFunc() (error) {
  filename := "myFile"
  f, myHandler(!, filename) := os.Open(filename)
}

this is equivalent to:

func MyFunc() (error) {
  f, err := os.Open(filename)
  if err != nil {
    return myHandler(err, filename)
  }
}

Although, in this simple case, it would suffice to do:

func MyFunc() (error) {
  filename := "myFile"
  f, fmt.Errorf("copy %s : %v", filename, !) := os.Open(filename)
}

With support for error with return values:

func MyFunc() (error) {
  filename := "myFile"
  f, myHandler(!, f) := os.Open(filename)
}

I'd expect most function calls using ! to remain rather compact.

Special case, but probably marginal.

func MyFunc() (error) {
  f, panic(!) := os.Open(filename)
}

And of course for the cases where an error doesn't imply an immediate return, then the existing "if err != nil" remains appropriate, as flow is continuing after the function call statement, and the error is treated as nothing more than a variable.

Thanks for your time parsing this late and naive suggestion.

[ianlancetaylor]

Has some similarities to #32884.

[ianlancetaylor]

I'm not fond of the way that the more complex variants put the error handling (the call to myhandler) before the actual work (the call to os.Open).

[ctlod]

I can understand that. Two function calls with orthogonal purposes on the same line is going to quickly feel like clutter, particularly if the error handling side is longer, and anything that makes the actual work less obvious is a no go.
I feel this would hold true whether the error handling comes on the left or the right of the actual work.

So if we exclude error handling on the same line, maybe all that's left is a handle keyword?

f, err := os.Open(filename)
if err != nil {
  return err
}

f, err := os.Open(filename)
handle err return err

f, err := os.Open(filename)
handle err return decorate(err)

f, err := os.Open(filename)
handle err {
	return decorate(err)
}

Reduces boilerplate, keeps returns explicit but not a significant improvement over a more relaxed format for if statements, for which I think there must already be another proposal somewhere.

f, err := os.Open(filename)
if err != nil { return err }

[ianlancetaylor]

handle err has some similarities to #32611.

[mvndaai]

I like that this proposal restricts the life of the err variable the line it is created.

I dislike that it makes error decoration more complex and forces an implicit return. Sometimes errors should be handled by logging, sometimes they should return, and in a loop they should continue or break.

[ctlod]

And a mix of both ! and "handle" (changed to catch, as it feels fitting) would give us:

! denotes that the error is returned, the "catch" allows to name the error variable and control flow for cases that require more than a simple return.

f, ! := os.Open(filename)

f, ! := os.Open(filename)
catch err {
  return decorate(err)
}

f, ! := os.Open(filename)
catch err {
  log(err)
  cleanup()
}

And as it's not an if, gofmt could allow:

f, ! := os.Open(filename)
catch err { return decorate(err) }

or even

f, ! := os.Open(filename)
catch err return decorate(err)

Restricts the scope of the error and reads easily enough but it's both a new key symbol and a new key word, so from what I gather, not popular.

The catch would not have to directly follow the !, but scope would then get interesting.

[mvndaai]

@ctlod I am one of the people that does not want inline if or catch statements. Mat Ryer made a point that if you avoid using else it is easy to see the happy path of a function by ignoring indented code. Inlining an if or catch would remove that ability.

[ctlod]

Gofmt could enforce the following if the catch can only ever intercept that one error and is a single line. This is all about minimizing vertical space for what might be considered "unimportant" compared to the actual work.

f, ! := os.Open(filename)
    catch err { return decorate(err) }

Catching multiple errors, or multiline catch, could look like:

func MyFunc() (error) {
    ...
    f, ! := os.Open(filename)
    defer f.Close()
    g, ! := os.Open(otherfilename)
    ...
   catch err {
       ...
    }
}

• Every ! becomes an auto-magic goto. (How to handle variable declarations? Goto rule too restrictive here)
• ! is always caught by the next catch in current or outer block.
• Any function using ! would require at least one catch after the last !. (Or implicit catch err { return err } )

In my opinion, enough proposals around to indicate that using a key symbol is intuitive enough when reducing boiler plate.
The challenge is whether it can be integrated into something that covers most "error" cases in a fashion that clearly outshines the current if err != nil.

[mvndaai]

@ctlod I am weary of multiline catches. It means that decoration is not specific to a function rather than an error. It also stops the ability to have different flows for different errors. Most errors I decorate and return. In a loop I either break,continue, or return. If the error shouldn't stop flow I log and move on.

[donaldnevermore]

The ! already means not in !=.

var r, ! = os.Open(filename)

The ! close to the = looks like !=.