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

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

From
Jeff King <peff@peff.net>
Date
Nov 4, 2017, 09:35 UTC
Message-ID
<20171104093537.glucmbljnjlw3htq@sigill.intra.peff.net>
In-Reply-To
<b074d6fa-8778-ea0d-d53b-7cc35bc4264a@web.de>
On Sat, Nov 04, 2017 at 10:05:43AM +0100, René Scharfe wrote:
Show 15 quoted lines
> >> How about *not* printing the error at the place where you notice the
> >> error, and instead return an error code to the caller to be noticed
> >> which dies with an error message?
> > 
> > That ends up giving less-specific errors.
> 
> Not necessarily.  Function could return different codes for different
> errors, e.g. -1 for an open(2) error and -2 for a write(2) error, and
> the caller could use that to select the message to show.
> 
> Basically all of the messages in wrapper.c consist of some text mixed
> with the affected path path and a strerror(3) string, so they're
> compatible in that way.  A single function (get_path_error_format()?)
> could thus be used and callers would be able to combine its result with
> die(), error(), or warning().

I think we've had this discussion before, a while ago. Yes, returning an integer error code is nice because you don't have pass in an extra parameter. But I think there are two pitfalls:

  1. Integers may not be descriptive enough to cover all cases, which is
     how we ended up with the strbuf-passing strategy in the ref code.
     Certainly you could add an integer for every possible bespoke
     message, but then I'm not sure it's buying that much over having
     the function simply fill in a strbuf.
  2. For complex functions there may be multiple errors that need to
     stack. I think the refs code has cases like this, where a syscall
     fails, which causes a fundamental ref operation to fail, which
     causes a higher-level operation to fail. It's only the caller of
     the higher-level operation that knows how to report the error.

Certainly an integer error code would work for _this_ function, but I'd rather see us grow towards consistent error handling.

-Peff
Previous: René ScharfeNext: Simon Ruderich
Message 24 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.