Re: RFC: error codes on exit

Jonathan Nieder [off-list ref] writes:

quoted

I am sympathetic to the cause and I agree that introducing a
finer-grained classification might be a solution.  I however am not
sure how we can enforce developers to apply such a manually assigned
"error code" cosistently.

I think two things you're hinting at are "what about maintainability?"
and "what is the migration path?"

Not really.  There is not much to migrate from, and mislabeling by
developers, or more realistically disagreement between developers
what label is appropriate for which condition that leads to die(),
would be a usability problem and not maintainability that I would be
worried about.

However, for analysis in aggregate (for example, to define an SLO[1])
that would require us to maintain a database that maps
<filename>:<lineno> to error code.  That database would be essentially
the same as patches to record the error codes, so what it would really
amount to is having these deployments using a permanent fork of Git.

Yes, the suggestion was to start from there to gain experience,
because ...

If we expect the error codes to not be useful to anyone else, then
that is the right choice to make (or rather, we'd have to use other
heuristics, such as having the traces record a collection of offsets
in the binary and a build-id so we can key off of stack trace
signatures).  Part of the reason I started this thread is to get a
sense of whether these can be useful to others.

... others will find it useful if the classification matches _their_
needs, but I suspect the "bin" a single die() location wants to be
classfied into would end up to be different depending on what the
log collecting entity is after.