Re: [RFC PATCH 1/1] Add a type for errors

[phillip.wood123@gmail.com]

Hi brian

On 02/10/2024 23:04, brian m. carlson wrote:
> On 2024-10-02 at 09:54:52, Phillip Wood wrote:
>> On 30/09/2024 23:03, brian m. carlson wrote:
>> Part of the reason it works well in rust is that it supports discriminated
>> unions with pattern matching and has the "?" macro for early returns. In C
>> the code ends up being quite verbose compared to taking a pointer to error
>> struct as a function parameter and returning a boolean success/fail flag.
>>
>>      struct git_error e;
>>      struct object_id oid;
>>
>>      e = repo_get_oid(r, "HEAD", &oid);
>>      if (!GIT_ERROR_SUCCESS(e))
>>          return e;
>>
>> With a boolean return we can have
>>
>>      struct object_id oid;
>>
>>      if (repo_get_oid(r, "HEAD", &oid, e))
>>          return -1;
>>
>> where "e" is a "struct git_error*" passed into the function.
> 
> Yes, I agree that this is more verbose than in Rust.  If we were using
> Rust (which is a thing I'm working on), then we'd have nicer error
> handling, but for now we don't.
> 
> However, Go still uses this kind of error handling, and many people use
> it every day with this limitation, so I don't think it's too awful for
> what we're getting.

I feel like I'm missing something - what is the advantage of returning 
an error struct rather than passing it as a parameter that makes the 
inconvenience of handling the return value worth while?

>> In conclusion I like the general idea but have concerns about the verbosity
>> of returning an error struct. It would be helpful to see some examples of
>> this being used to see how it works in practice.
> 
> If I send a v2, I'll try to wire up some code so folks can see some
> examples.

I think that would be really helpful. A couple of examples in the cover 
letter showing how you'd convert some function from our codebase would 
give us an idea of what using this api would look like in practice.

Best Wishes

Phillip