From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 28 Apr 2015 23:34:07 GMT
Subject: Re: [PATCH v5 1/5] setup: add gentle version of read_gitfile
Message-ID: <xmqq383jvndc.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150428204853.GA12153@peff.net>

Jeff King <peff@peff.net> writes:

> Yes, I agree converting the integer back into a string later does not
> always carry all of the data. OTOH, the caller can often supply the
> context (i.e., this is basically how "errno" works). This gets back to
> the idea we discussed a while ago of having a "struct error" that can
> carry the code and the parameters (or if you like, the code and a
> finished error message). It just feels in some ways like that ends up
> with the worst of both worlds (a lot of boilerplate for integer codes,
> _and_ the allocation and cleanup issues associated with a string error
> message).
>
> I dunno. I'd be interested to see a rough draft of an idea applied to a
> specific callsite.

For this specific callsite, I think the error code alone is the
right way forward. It conveys all information necessary out of the
callee back to the caller, so that the caller, when it decides to do
so later, can turn error code to human readable form.

For some callsites, there may be cases where carrying a centrally
produced string may be a handy way to grab detailed error message
out of a deep call chain, but even in such a case, it is likely that
we would need a separate error code, and a funtion that returns a
pointer as its primary return value would need "two" extra out
parameters, one for message and one for code.