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.
