Re: [PATCH 0/5] promise: introduce promises to track success or error

[Jeff King <peff@peff.net>]

On Tue, Feb 20, 2024 at 01:19:16PM +0100, Patrick Steinhardt wrote:

> While we're already at it throwing ideas around, I also have to wonder
> whether this would be a long-term solution towards computer-friendly
> errors. One of the problems we quite frequently hit in Gitaly is that we
> are forced to parse error messages in order to figure out why exactly
> something has failed. Needless to say, this is quite fragile and also
> feels very wrong.
> 
> Now if we had a more structured way to pass errors around this might
> also enable us to convey more meaning to the caller of Git commands. In
> a hypothetical world where all errors were using an explicit error type,
> then this error type could eventually become richer and contain more
> information that is relevant to the calling script. And if such rich
> error information was available, then it would not be that far fetched
> to ask Git to emit errors in a computer-parsable format like for example
> JSON.

I think what I'm proposing (and if I understand correctly what Phillip
was thinking) is somewhat orthogonal. I agree that structured errors are
nice for computers to read. But it does open up a pretty big can of
worms regarding classifying each error, especially as root causes are
often multi-level.

For example, imagine that the caller asks to resolve a ref. We might get
a syscall error opening the loose ref. Or we might get one opening the
packed-refs file (in a reftable world, you might imagine errors opening
various other files). What is the structured error? Obviously it is "we
can't resolve that ref" at some level. But the caller might want to know
about the failed open (whether it is just ENOENT, or if we ran into
EPERM or even EIO).

Or looking at higher levels; if I ask for the merge base between A and
B, but one of those can't be resolved, how do we communicate that error?
It is some sort of "cannot resolve" error, but it needs to be
parameterized to know which is which.

All of those questions can be answered, of course, but now we are
developing a micro-format that lets us describe all errors in a
standardized way. And I think that is going to put a burden on the code
which is generating the errors (and potentially on the consumers, too,
if they have to decipher the structure to figure out what they want).

Whereas what I was really advocating for is punting on the structured
thing entirely. We keep our unstructured string errors for the most
part, but we simply let the caller pass in a context that tells us what
to do with them. That lets us keep providing specific error messages
from low-level functions without printing to stderr or exiting, which
higher-level code (especially lib-ified code) would not want.

I think it could also be the first building block for making more
structured errors (since those low-level callers are free to provide
lots of details), but it doesn't have to be.

-Peff