proposal: Go2 error handling for error-tree

[Konstantin8105]

Please add into wiki Go2ErrorHandling, my proposal for error handling in error-tree. Preview:

func printSum(a, b string) error {
  // create error tree
  et := errors.New("check input data")
  errorhandling(et interface{Add(error)}){ // add type just for clearification
    x, et := strconv.Atoi(a)
    y, et := strconv.Atoi(b)
  }
  // is error-tree have errors
  if et.IsError() {
    return et
  }
  fmt.Println("result:", x + y)
  return nil
}

In detail see: Go2ErrorTree

[ianlancetaylor]

CC @jba @neild

[jba]

It looks like there are two ideas here. One is an "error tree" type that can collect multiple errors. It seems that this type is itself an error, but it can also represent the state of there being no errors. So it is already incompatible with the basic property of Go error handling, that there is an error if and only if err != nil.

The second idea is some new syntax for automatically collecting errors into an error tree. That results in simpler control flow (no if err checks) for code where several actions are taken independently. I believe that is rare, however; it's much more common for an action to depend on the result of a previous action. In those cases, the special syntax will obscure bugs. For example, in this code:

errorhandling(et interface{Add(error)}) {
   a, et := f()
   b, et := g(a)
}

we erroneously pass a garbage a to g when f returns an error.

[Konstantin8105]

Yes, @jba, you are right. Syntax errorhandling is work fine, only if expessions inside are independancy.
And you example looks like(it is valid code see https://play.golang.org/p/xl5dRJgvKqU):

  a, err := f() 
  // no error checking
  b, err := g(a)
  if err != nil{
    return err
  }

but in that case we will not see error from function f(). If we use errorhandling, then error will garantee added in error-tree.

[networkimprov]

@Konstantin8105 what are the problems and solution requirements that motivated your proposal?

FYI, I've collected a menu of Requirements to Consider for Go 2 Error Handling.

Also, please feel free to add a link to your proposal to the wiki:
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

[Konstantin8105]

Now, I add to wiki https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

[ianlancetaylor]

Thanks for this proposal. This combines error handling and error values into a single proposal. But the idea is somewhat complicated: it requires a builtin type more complicated than error, and it requires additional control within the errorhandling construct. It also seems to implicitly call an Add method, which is not something we ever do in the language today.

We aren't going to adopt this idea.