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

Re: RFC: error codes on exit

From
JHJeff Hostetler <git@jeffhostetler.com>
Date
May 20, 2021, 15:09 UTC
Message-ID
<795fd316-2bb5-e382-b104-85d1aaa09a1c@jeffhostetler.com>
In-Reply-To
<YKWggLGDhTOY+lcy@google.com>
On 5/19/21 7:34 PM, Jonathan Nieder wrote:
Show 26 quoted lines
> Hi,
> 
> (Danger, jrn is wading into error handling again...)
> 
> At $DAYJOB we are setting up some alerting for some bot fleets and
> developer workstations, using trace2 as the data source.  Having
> trace2 has been great --- combined with gradual weekly rollouts of
> "next", it helps us to understand quickly when a change is creating a
> regression for users, which hopefully improves the quality of Git for
> everyone.
> 
> One kind of signal we haven't been able to make good use of is error
> rates.  The problem is that a die() call can be an indication of
> 
>   a. the user asked to do something that isn't sensible, and we kindly
>      rebuked the user
> 
>   b. we contacted a server, and the server was not happy with our
>      request
> 
>   c. the local Git repository is corrupt
> 
>   d. we ran out of resources (e.g., disk space)
> 
>   e. we encountered an internal error in handling the user's
>      legitimate request
...

For the error event that `error()` and `die()` and friends generate, I emit both the fully formatted error message and the format string.

The latter, if used as a dictionary key, would let you group like events from different processes without worrying about the filename or blob id or remote name or etc. in any one particular instance.

Would that be sufficient as an error classification and something that you can key off of in your post-processing ?

Granted the same format message might be used in multiple places in the source, but I also provide the source filename and line number.

If it turns out that all of the error events come from "usage.c" (i.e. error_builtin() or die_builtin()), then maybe we need to look at another way of wrapping those calls to pass the F/L of actual caller. I hesitated to do that because of the existing indirection tricks in usage.c WRT the `set_error_routine()` and friends. (And that assumes that the format string is a viable solution for you problem.)

Jeff
Previous: Jeff KingNext: brian m. carlson
Message 23 of 26 in “RFC: error codes on exit”
  1. Jonathan NiederMay 19, 2021
  2. Felipe ContrerasMay 20, 2021
  3. Alex HenrieMay 21, 2021
  4. H. Peter AnvinMay 21, 2021
  5. Bagas SanjayaMay 22, 2021
  6. Junio C HamanoMay 22, 2021
  7. H. Peter AnvinMay 22, 2021
  8. Felipe ContrerasMay 22, 2021
  9. H. Peter AnvinMay 22, 2021
  10. Felipe ContrerasMay 22, 2021
  11. H. Peter AnvinMay 22, 2021
  12. Philip OakleyMay 22, 2021
  13. Felipe ContrerasMay 22, 2021
  14. Alex HenrieMay 25, 2021
  15. Felipe ContrerasMay 25, 2021
  16. Junio C HamanoMay 20, 2021
  17. Felipe ContrerasMay 20, 2021
  18. Jonathan NiederMay 20, 2021
  19. Junio C HamanoMay 20, 2021
  20. Jeff KingMay 20, 2021
  21. Jonathan NiederMay 20, 2021
  22. Jeff KingMay 21, 2021
  23. Jeff HostetlerMay 20, 2021
  24. brian m. carlsonMay 21, 2021
  25. brian m. carlsonMay 21, 2021
  26. Ævar Arnfjörð BjarmasonMay 26, 2021

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.