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

Re: [PATCH 1/2] sequencer: factor out rewrite_file()

From
Simon Ruderich <simon@ruderich.org>
Date
Nov 4, 2017, 18:36 UTC
Message-ID
<20171104183643.akaazwswysphzuoq@ruderich.org>
In-Reply-To
<20171103191309.sth4zjokgcupvk2e@sigill.intra.peff.net>
On Fri, Nov 03, 2017 at 03:13:10PM -0400, Jeff King wrote:
> I think we've been gravitating towards error strbufs, which would make
> it something like:

I like this approach to store the error in a separate variable and let the caller handle it. This provides proper error messages and is cleaner than printing the error on the error site (what error_errno does).

However I wouldn't use strbuf directly and instead add a new struct error which provides a small set of helper functions. Using a separate type also makes it clear to the reader that is not a normal string and is more extendable in the future.

> I'm not excited that the amount of error-handling code is now double the
> amount of code that actually does something useful. Maybe this function
> simply isn't large/complex enough to merit flexible error handling, and
> we should simply go with René's original near-duplicate.

A separate struct (and helper functions) would help in this case and could look like this, which is almost equal (in code size) to the original solution using error_errno:

    int write_file_buf_gently2(const char *path, const char *buf, size_t len, struct error *err)
    {
            int rc = 0;
            int fd = open(path, O_WRONLY | O_CREAT | O_TRUNC, 0666);
            if (fd < 0)
                    return error_addf_errno(err, _("could not open '%s' for writing"), path);
            if (write_in_full(fd, buf, len) < 0)
                    rc = error_addf_errno(err, _("could not write to '%s'"), path);
            if (close(fd) && !rc)
                    rc = error_addf_errno(err, _("could not close '%s'"), path);
            return rc;
    }

(I didn't touch write_in_full here, but it could also take the err and then the code would get a little shorter, however would lose the "path" information, but see below.)

And in the caller:
    void write_file_buf(const char *path, const char *buf, size_t len)
    {
            struct error err = ERROR_INIT;
            if (write_file_buf_gently2(path, buf, len, &err) < 0)
                    error_die(&err);
    }

For now struct error just contains the strbuf, but one could add the call location (by using a macro for error_addf_errno) or the original errno or more information in the future.

error_addf_errno() could also prepend the error the buffer so that the caller can add more information if necessary and we get something like: "failed to write file 'foo': write failed: errno text" in the write_file_buf case (the first error string is from write_file_buf_gently2, the second from write_in_full). However I'm not sure how well this works with translations.

We could also store the error condition in the error struct and don't use the return value to indicate and error like this:

    void write_file_buf(const char *path, const char *buf, size_t len)
    {
            struct error err = ERROR_INIT;
            write_file_buf_gently2(path, buf, len, &err);
            if (err.error)
                    error_die(&err);
    }
Show 15 quoted lines
> OTOH, if we went all-in on flexible error handling contexts, you could
> imagine this function becoming:
>
>   void write_file_buf(const char *path, const char *buf, size_t len,
>                       struct error_context *err)
>   {
> 	int fd = xopen(path, err, O_WRONLY | O_CREAT | O_TRUNC, 0666);
> 	if (fd < 0)
> 		return -1;
> 	if (write_in_full(fd, buf, len, err) < 0)
> 		return -1;
> 	if (xclose(fd, err) < 0)
> 		return -1;
> 	return 0;
>   }

This looks interesting as well, but it misses the feature of custom error messages which is really useful.

Regards Simon

-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Previous: Jeff KingNext: Jeff King
Message 25 of 35 in “sequencer: factor out rewrite_file()”
  1. 1/2 sequencer: factor out rewrite_file()René Scharfe, Oct 31, 2017
  2. 2/2 sequencer: use O_TRUNC to truncate filesRené Scharfe, Oct 31, 2017
  3. Kevin DaudtOct 31, 2017
  4. Johannes SchindelinNov 1, 2017
  5. Kevin DaudtOct 31, 2017
  6. Kevin DaudtNov 1, 2017
  7. Simon RuderichNov 1, 2017
  8. René ScharfeNov 1, 2017
  9. 1/2 wrapper.c: consistently quote filenames in error messagesSimon Ruderich, Nov 1, 2017
  10. Junio C HamanoNov 2, 2017
  11. Junio C HamanoNov 2, 2017
  12. Simon RuderichNov 2, 2017
  13. Junio C HamanoNov 3, 2017
  14. 2/2 sequencer.c: check return value of close() in rewrite_file()Simon Ruderich, Nov 1, 2017
  15. René ScharfeNov 1, 2017
  16. Johannes SchindelinNov 1, 2017
  17. Jeff KingNov 1, 2017
  18. Johannes SchindelinNov 1, 2017
  19. Jeff KingNov 1, 2017
  20. Simon RuderichNov 3, 2017
  21. Junio C HamanoNov 3, 2017
  22. Jeff KingNov 3, 2017
  23. René ScharfeNov 4, 2017
  24. Jeff KingNov 4, 2017
  25. Simon RuderichNov 4, 2017
  26. Jeff KingNov 5, 2017
  27. Simon RuderichNov 6, 2017
  28. Simon RuderichNov 16, 2017
  29. Jeff KingNov 17, 2017
  30. Johannes SixtNov 18, 2017
  31. Jeff KingDec 24, 2017
  32. Randall S. BeckerDec 24, 2017
  33. Johannes SixtDec 25, 2017
  34. Johannes SchindelinNov 3, 2017
  35. Jeff KingNov 3, 2017

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.