git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Oct 2, 2024, 22:16 UTC
Message-ID
<CAPig+cRkA58wr_Pn-uhVM0zFA7B0hnArXDeumrjnWrgBbG64Yw@mail.gmail.com>
In-Reply-To
<Zv3DehUxEN6SJI1M@tapette.crustytoothpaste.net>

On Wed, Oct 2, 2024 at 6:04 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 28 quoted lines
> On 2024-10-02 at 09:54:52, Phillip Wood 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.
>
> 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 won't say that Go is my favourite language and I
> do prefer the less verbose error handling in Rust, but the fact that
> this design is widely used means that it's at least a defensible
> decision.

I'm not sure I understand your response to Phillip's observation. Idiomatic error handling in Go:

    if oid, err := repo_get_oid(r, "HEAD"); err != nil {
        return err;
    }

seems much closer to Phillip's more succinct example than to the more verbose example using GIT_ERROR_SUCCESS().

Previous: brian m. carlsonNext: brian m. carlson
Message 12 of 21 in “Typed errors”
  1. 0/1 Typed errorsbrian m. carlson, Sep 30, 2024
  2. 1/1 Add a type for errorsbrian m. carlson, Sep 30, 2024
  3. Junio C HamanoSep 30, 2024
  4. brian m. carlsonSep 30, 2024
  5. Patrick SteinhardtOct 21, 2024
  6. Oswald BuddenhagenOct 1, 2024
  7. Phillip WoodOct 2, 2024
  8. Emily ShafferOct 1, 2024
  9. brian m. carlsonOct 2, 2024
  10. Phillip WoodOct 2, 2024
  11. brian m. carlsonOct 2, 2024
  12. Eric SunshineOct 2, 2024
  13. brian m. carlsonOct 2, 2024
  14. Eric SunshineOct 3, 2024
  15. Junio C HamanoOct 3, 2024
  16. Eric SunshineOct 3, 2024
  17. brian m. carlsonOct 4, 2024
  18. phillip.wood123@gmail.comOct 4, 2024
  19. Richard KerryOct 4, 2024
  20. Emily ShafferOct 3, 2024
  21. phillip.wood123@gmail.comOct 4, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.