Re: Proposal/Discussion: Turning parts of Git into libraries

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <nasamuffin@google.com> writes:

> Is there a reason not to use this kind of struct and provide
> library-specific error code enums, though, I wonder? You're right that
> parsing the error string is really bad for the caller, for anything
> besides just logging it. But it seems somewhat reasonable to expect
> that any call from config library returning an integer error code is
> referring to enum config_errors...

In addition to what Peff already said, I think the harder part of it
is to parametralize the errors in a machine readable way.  A part of
a library may say (with an enum) that it is returning "Ref cannot be
read" error, with a parameter that says "The ref that caused this
error was 'refs/heads/next'" which makes "Ref cannot be read" error
has one parameter.  "Ref cannot be renamed" may have two (old and
new name).  Other errors from some library functions may not even be
of type "string".

Coming up with the enums to cover the error conditions (which Peff
covered well) is already a lot of work.  Making sure each of them
take sufficient parameters to describe the error usefully adds more
on top.  And the code to pass these variable number of parameters of
variable types would be, eh, fun---it would be error prone without
compiler help.