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

From: Jeff King <peff@peff.net>
Date: Feb 21, 2024, 18:03 UTC
Message-ID: <20240221180354.GE634809@coredump.intra.peff.net>
In-Reply-To: <ZdSYxF3Hd6Zqt3Wd@tanuki>

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

Show 15 quoted lines

> 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