[error handling] RFC 'else'

180 views
Skip to first unread message

Oliver Smith

unread,
Dec 2, 2020, 2:57:13 PM12/2/20
to golang-nuts
Do I understand correctly that "last return value is error" is purely convention and there is no formal error handling in current go?

My instinct is to leverage the 'else' keyword along with the notion of a "stock error whose return list's last element is type error with value != nil.

  func not_stock() (int, interface{})
  func stock() error
  func stock() (int, error, string, float, error, error, error)
  func not_stock() (error, error, error, int)
  func stock() (error, error)

Any other type of error handling can still be handled as the user wishes, stock errors simply provide syntax to lean into, and that syntax would be: 
 
    [ <assignment> ] <call expr> ast.ELSE <block statement>

e.g.

    file, err := io.Open(file) else {
      return nil, err
    }
    fh.Close() else {
      panic("close call failed")
    }

Equivalent to:

    file, err := io.Open(file)
    if err != nil {
      return nil, err
    }
    if err := fh.Close(); err != nil {
      panic("close call failed")
    }

One of the current nuisances of error handling is that it can break the clean flow of variable assignments, forcing you to add separate declarations or scopes. Given a function

   func NewStruct() (s *Struct, sz int, err error)

you typically have two very different lifespans for the return values

   s, sz, err := NewStruct()
   if err != nil {  // last reference to err in function

vs

    if s, sz, err := NewStruct(); err != nil {
      panic(err)
    } else {
      // to access s and sz
    }

or

    var (
      s *Struct
      sz int
      err error   // but literally only for one line
    )
    if s, sz, err = NewStruct(); err != nil {
      panic(err)
    }

Using the else construct always allows the shorter form, which is at least consistent:

    // not a sub-clause so s, sz and err introduced in current scope level.
    s, sz, err := NewStruct() else {
      panic(err)
    }

The fly in the ointment here is ... where does the error go if you don't mention it?

    fh.Close() else {
      panic(?what?)
    }

the lazy option would be `_`

    fh.Close() else {
      fmt.Errorf("unexpected close failure: %s", _)
      err := _
      panic(err)
    }

But I think we can avoid the path of perl, and simply require capture if you want the value surfaced.

    err := fh.Close() else {
      panic(err)
    }

seank...@gmail.com

unread,
Dec 2, 2020, 3:30:24 PM12/2/20
to golang-nuts
see also

Viktor Kojouharov

unread,
Dec 3, 2020, 6:15:52 AM12/3/20
to golang-nuts
Also a lot of the proposals listed in the `Wrapping` section of
https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/
Reply all
Reply to author
Forward
0 new messages