Patrick Steinhardt <ps@xxxxxx> writes:
> Furthermore, I do think it's more explicit what the functions are
> doing when there is a 'or_die' suffix. Without this suffix it may
> be unexpected that the functions simply abort the program
> whenever an error occurs.
That largely depends on what you are used to see. Many internal API
functions do "if we cannot do this, die" without or_die suffix.
As the endgame state, I'd find it far more preferrable to see a
function that dies without _or_die(), while allowing outlier callers
to call the _gently() variant to do their own clean-up [*1*].
How we get to that endgame is a different matter. It is a viable
approach like you did in the original series to first temporarily
introduce _or_die() and convert the current callers in small chunks.
The second step would be to rename git_config_set() and friends that
do not die to hae _gently() suffix, and update the remaining callers
to call them. At that point, nobody calls git_config_set(), so we
can drop the _or_die() suffix, which would lead us to the endgame
state.
But because we are talking about only a very small number of
callers, I think either is OK.
Thanks.
[Footnote]
*1* Another consideration while talking about a transition like this
is what would happen in topics in flight (either in my tree
above 'next' or people privately are working on). New callsites
they added expecting git_config_set() to return error would have
to be adjusted to call _gently() variants, and we need to catch
such sites somehow. In this partcular transision, it can easily
be done and you've done so already by making the functions
return no value, so anybody who checked their return values
would be flagged by the compiler.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html