Missing Multiple Error Handlers (a Revised Handler Concept), re Go2 handle/check proposal

txt.md

Now posted on the golang issue tracker, #27519.

The #id/catch error model, a revision of check/handle

Appreciations to the Go team for presenting a thoughtful and detailed set of Go2 draft designs. The Error Handling Draft is great for logging errors via the handler chain, and returning them succinctly. However, Go programs commonly:

a) handle an error and continue the function that received it, and
b) have two or more kinds of recurring error handling in a single function, such as:

{ log.Println(err.Error()); return err }
{ log.Fatal(err) }
{ if err == io.EOF { break } }
{ conn.Write([]byte("oops: " + err.Error())) } // e.g. a network message processor

The check/handle scheme doesn't accommodate these patterns, necessitating an awkward mix of Go1 & Go2 idioms:

if err = f(); err != nil {
   if isSerious(err) { check err }
   // handle recoverable error
}

And there are other problems, outlined in Why Not check/handle below.

The #id/catch Error Model

func (db *Db) GetX(data []byte) (int, error) {
   n, #_   := db.name()                          // return our own errors via default handler
   
   f, #err := os.Open(n)                         // this file's presence is optional
   defer f.Close()
   _, #err  = f.Seek(42, io.SeekStart)
   l, #err := f.Read(data)
   
   #_ = db.process(data)
   
   catch err error {                             // handle OS errors here
      if !os.IsNotExist(err) { log.Fatal(err) }
      log.Println(n, "not found; proceding")
      #err = nil                                 // resume (should be the default?)
   }
   return l, nil
}

Here a catch identifier (catch-id) e.g. #err selects an error handler. A single catch-id may appear in any assignment. A handler is known by its parameter name; the parameter can be of any type. Handlers with the same parameter name in related scopes form a chain. A handler follows the catch-id(s) that trigger it and starts with keyword catch. Catch-ids are not variables and handler parameters are only visible within handlers, so there's no re-declaration of error variables.

Several points are unresolved, see Open Questions below. Catch-id syntax is among them; #id is reminiscent of the URL form for goto id, but ?id, @id, and others are viable.

Please help clarify (or fix) this proposal sketch, and describe your use cases for its features.

Feature Summary

We can select one of several distinct handlers:

func f() error {
   v1, #fat := fatalIfError()     // a non-zero value for #id triggers the corresponding catch
   v2, #wrt := writeIfError()

   v3, #_   := returnIfError()    // default handler, returns the value if triggered
   v4, #!   := panicIfError()     // default handler, panics if triggered; for callers that don't return
   
   catch fat error { log.Fatal(fat) }             // if type is error, type name could be optional
   catch wrt error { con.Write(...); return nil } // return/exit required in last handler on chain
}

We can chain handlers across scopes, as in the Error Handling Draft:

func f() {
   v, #fat := x()
   if v != nice {                                 // new scope
      #fat = y(&v)
      catch fat error { debug.PrintStack() }      // no return/exit; chained with next catch fat
   }
   catch fat error { log.Fatal(fat) }             // parameter types must be the same across the chain
}

We can invoke a handler defined at package level (thanks @8lall0):

func f() error {
   #pkg = x()
   catch pkg { ... }        // optional
}

catch pkg {                 // package-level handler
   log.Println(pkg.Error())
   return pkg               // return signature must match function invoking pkg handler
}

We can cancel the chain and resume after the handler:

   #err = f()
   catch err { log.Println(...); #err = nil }  // exit handler; don't goto next handler in chain
                                               // can be the only/last handler in chain
   x()                                         // called after handler

We can change the input for the next chained handler:

   if t {
      #err = f()
      catch err {
         if ... {
            #err = MyError{...}  // exit handler; set input for next handler in chain
         } else {
            err = nil            // no effect on next handler
         }
      }
   }
   catch err { return err }      // if missing, compiler complains about self-invocation

We can forward to a different handler chain (can be applied to create an explicit chain in lieu of an implicit one):

   if ... {
      #err = f()
      catch err { if ... { #ret = err } }  // exit handler; pass err to handler in same or outer scope
                                           // err must be non-zero
   }
   catch ret { ... }
   catch err { ... }                       // may not be called

We can see everything from the scope where a handler is defined, like closure functions:

   v1 := 1
   if t {
      v2 := 2
      #err = f()
      catch err { x(v1, v2) }
   }

We can still use Go1 error handling:

   v1, err := x()  // OK
   v2, err := y()  // but re-declaration might be abolished!

Open Questions

• What catch-id syntax? #id, ?id, @id, id!, $id, ...
• What catch-id for default handlers? #_, #!, #default, #panic, ...
• What handler definition syntax? catch id, catch id type, catch (id type), except id, ...
• Require #id or _ for return values of type error?
• Provide check functionality with f#id()? e.g. x(f1#_(), f2#err())
  If so, disallow nesting? x(f1#err(f2#err()))
• Allow unused handler?

   func f() {
      catch ret { ... }   // unused
      #ret = x()
      catch ret { ... }   // OK; preceding catch-id selects this
      catch err { ... }   // unused
   }
  

• Drop implicit handler chaining? (Handler default action would be resume.)

   if ... {
      #err = f1()
      catch err { log.Println(...) }
   }
   #err = f2()
   catch err { return nil } // sees errors from f1 & f2; was f2 the only intended source?
  

• Provide more context to package-level handlers, e.g. caller name, arguments?

   catch pkg, caller {
      log.Println(caller, pkg.Error())
   }
  

• Allow multiple handler arguments?

   #val, #err = f()               // return values must be assignable to catch parameter types
   catch val T, err error { ... } // either parameter could be non-zero
  

Disallowed Constructs

Reading a catch-id:

   #err = f()
   if #err != nil { ... }   // compiler complains
   catch err { ... }

Multiple catch-ids per statement:

   #val, #err = f()   // compiler complains
   catch val { ... }  // if f() returns two non-zero values, which handler is executed?
   catch err { ... }

Shadowing of local variables in handlers:

func f() {
   if t {
      err := 2
      #err = f()            // OK; #err handler can't see this scope
   }
   pkg := 1                 // OK; #pkg handler (see above) can't see local variables
   err := 1
   #err = f()
   catch err { return err } // compiler complains; err==1 is shadowed
}

Contiguous handlers with the same catch-id and scope:

   #err = f()
   catch err { ... }
   #ret = f()
   catch err { return err }  // compiler complains
   catch ret { ... }
   catch ret { return ret }  // compiler complains

Why Not check/handle?

• check is specific to type error and the last return value.
• check doesn't support multiple distinct handlers.
• Function call nesting with a per-call unary operator can foster unreadable constructions:
  f1(v1, check f2(check f3(check f4(v4), v3), check f5(v5)))
  May I remind you, we are forbidden this: f(t ? a : b)
• The outside-in handle chain can only bail out of a function.
• Handlers that add context should appear after the relevant calls, in the order of operations:

   for ... {
      #err = f()
      catch err { #err = fmt.Errorf("loop: %s", err.Error()) }
   }
   catch err { return fmt.Errorf("context: %s", err.Error()) }
  

• There is relatively little support for the draft design on the feedback wiki.

Named Handlers Are Popular!

At last count, more than 1/3rd of posts on the feedback wiki suggest ways to select one of several handlers:

1. @didenko github
2. @forstmeier gist
3. @mcluseau gist
4. @the-gigi gist
5. @PeterRK gist
6. @marlonche gist
7. @alnkapa github
8. @pdk medium
9. @gregwebs gist
10. @gooid github
11. @networkimprov this page

/cc @rsc @mpvl @griesemer @ianlancetaylor @8lall0 @sdwarwick @kalexmills
@gopherbot add Go2 LanguageChange Proposal

Thanks for your consideration,
Liam Breck
Menlo Park, CA, USA

@8lall0, thanks for your input! Great idea to allow package-level catch pkgVar error {...}! I've added that to my text.

I suggested catches at top or bottom of scope, but not anywhere. I want them at the bottom because a handler could be long, and I find it odd to read what to do last at the top of a scope. However that could be mitigated by allowing local-scope func f() {...} (i.e. not f := func(){...}) to appear anywhere in a function and be callable before it appears.

very much agree that multiple handlers should be possible.
another aspect not being discussed is testing - what syntax would make a testing harness easiest?

I think the new catch-handle feature already would make Go code slightly harder to grasp quickly in some places. This alternative concept would reduce readability even more.

@dchenk, how so? My concept is simpler than the proposal. Most code would look like:

func x() error {
   #err = f1() // #flag is more noticeable than check
   #err = f2()
   catch err { return err }
}

The more i read the catch syntax, the less i like. I would prefer a func()-like syntax, to avoid unreadability, or maybe:

#err = func(var T, err error) {}

Also i don't like this:

 err := 1    // compiler complains here
 #err = f()  // or here

I see better:

 err := 1    // still legal, i want to be free (and "err" becomes type int,
             // so compiler complains if i want it afterwars as an Error type)
 #err = f()  // compiler complains if it isn't an error handling function
             // or if err is already declared with a different type, because it's a new assignment.

EDIT by owner to break comment lines
EDIT: some changes and something i read bad :)

Can you give more context for this? I'm not sure what it replaces...

#err = func(var T, err error) {}

Instead of:

catch err { log.Fatal(err) }

this:

#err = func(err Error) { log.Fatal(err) }

When you do assignment with #, it allows only a function that contains at least an Error parameter on input.

Tl;dr: #err = func() is just a short way to write, replicate and reuse if (err != nil) { ... }, like Rust macros.

EDIT: fixed the shadowing restriction, thanks!

#err = f() in my text can be assignment of anything, not just type error from a function call. Any non-zero value triggers the handler. And it could be extended to look for a specific value per handler...

I agree with the orig proposal that we need a distinct keyword for the handlers. And this is an exception scheme, so catch is the natural choice. Also I want to change their proposal as little as possible, as I assume they put a lot of thought into it...

I'm gradually building up a counter-proposal here to be posted in the golang issue tracker. I'll be banging on this a lot over the weekend :-)

The need for distinct variables names for different types of errors is well taken, but I don't know why we need any sort of # symbol or its variants, given that errors are already assigned to variables today. What is the difference between the first Features example and this rewrite?

func f() error {
   v1, fat := fatalIfError()   
   v2, wrt := writeIfError()
   v3, _   := returnIfError()    
   
   handle fat { log.Fatal(fat) }        
   handle wrt { con.Write(...); return nil }
}

I am wary of changing the input for the next handler in the chain. I shouldn't have to waste too many cycles thinking about where the error I got at the command-line came from. It seems like swapping inputs about makes that sort of tracing inevitable.

Finally, I think an argument could be made that using catch as reminiscent of C / Java could be more confusing for folks who might it to act like catch does in other languages. A handle keyword indicates the difference.

@kalexmills, thanks for your input.

err := f() appears to declare an ordinary variable (usually checked with if err != nil). If (much) later handle err magically makes it a handler invocation, that's easily overlooked. I think we should flag the special case, so the reader knows to look for a handler.

Re changing input to next handler in chain, a use case:

#err = f1()
if state_x {
   #err = foreignPackage.F()                 // we have no control over what errors this returns
   catch err {
      if odd_case { #err = fmt.Errorf(...) } // fix an error value which foreignPackage messes up
      ...                                    // add context about 'state_x'
   }
}
catch err { ... }                            // we get consistent error values

What features of catch from C++/Java/JavaScript are you referring to?