[TOPIC 03/11] Structured Error Handling

[Taylor Blau <me@ttaylorr.com>]

Structured Error Handling
=========================

(moderator: brian, notetaker: jrnieder)

* brian: idea for structured error handling!
   * Very little needed - pointer to error string, uint64_t error code,
     and ??  (third thing I didn't hear). Return it on the stack. Rust
     does this kind of thing all the time.
   * Having that structured return value lets a caller decide what to do
     with it
     - print a message, decide whether to exit or recover, etc.
* Patrick: a few requirements
   * want to attach arbitrary metadata to an error (e.g. "I had a
     conflict between that file and that file for this revision").
     Especially useful on the server side.
   * avoid having to parse error messages. Gitaly runs into this. Can
     imagine setting an envvar to get json or some other parsable format
     instead of human-consumable error messages.
* brian: sounds doable. GitHub also has the same hassle with parsing
  error messages.
* Peff: in your proposal, low-level code produces the error struct which
  is consumed at a higher level. Sometimes, though, you have many errors
  that are related.
   * "I couldn't merge these files because I couldn't open this file,
     because of this errno".
* One thing we've considered is having a callback to decide what to do
   * - print the error, collect into a tree of errors, etc.
   * The point is to keep what's happening in the generators of errors
     as simple as possible - I have this type of error and maybe some
     kind of context strings. That context could be owned by the caller,
     the callee can be responsible for copying it, etc. Inversion of
     control.
* Patrick: I like the way Go does things, can wrap errors or append
  messages, return up the stack until someone handles the error. Why are
  we afraid of allocations?
   * Peff: What do you do when the allocation fails?
   * Patrick: can handle allocation failure by having a special error
     that has a statically allocated string.
   * Peff: sounds good, getting rid of die() on alloc failure is okay
   * brian: Rust panics on out-of-memory anyway
   * Peff: there are two different cases - small allocations are "you're
     in trouble anyway", big allocation of user-supplied length is
     something else
   * Carlos: Rust has a "try to allocate memory", relatively new
* Calvin: how do you propagate up the call stack?
   * Peff: in my proposal, every function would take an error context
     struct, call the callback when there's an error, and keep the
     integer function returns. In brian's proposal, we instead return
     the struct.
   * Emily: Are we comfortable with the amount of churn that generates
     in the codebase?
   * Patrick: my inspiration is Subversion in that respect. It has nice
     error handling in C, they're a role model for me in how to do a
     library. It has nice error types that aren't a hassle to use.
   * J6t: if you compile in C++ and use exceptions, the problem has been
     solved 25 years ago.
   * brian: allocating strings for errors and then freeing them is a
     hassle in C. Versus Rust where that's handled automatically.
   * Emily: so it sounds like this is temporary pain
* Jonathan: I like Patrick's description of requirements. One thing that
  would make me more comfortable with the churn is when we get benefit
  even from partial conversion
   * E.g. could say we get structured error messages for the call sites
     that have been converted and not from others. And when I go on a
     debugging quest and wish I had a machine-readable structured error
     message, I can send a patch to convert more call sites
   * Peff: Refs code uses its own strbuf based error handling which is
     worse in every way than the options we've been discussing. :) That
     can be a good playground to try things out.
   * Patrick: +1, seems like a good place to start.