Jeff King writes:
> On Tue, Feb 17, 2015 at 08:03:00AM -0800, Junio C Hamano wrote:
>
>> > Whether or not we decide on a different error-handling convention in the
>> > future, it is a fact of life that a good bit of code already uses the
>> > "strbuf" convention documented by Jonathan's patch. S
Michael Haggerty writes:
>> I think we all agree that the early part of the new documentation
>> text is good, but the last section that proposes to store more
>> detailed errors in caller supplied strbuf in textual form was
>> controversial (and I have not convinced myself it is a good idea
>> y
On Tue, Feb 17, 2015 at 08:03:00AM -0800, Junio C Hamano wrote:
> > Whether or not we decide on a different error-handling convention in the
> > future, it is a fact of life that a good bit of code already uses the
> > "strbuf" convention documented by Jonathan's patch. So I think it is OK
> > to
On 02/13/2015 12:08 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
>>> On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
>>>
I am more worried about variable length part pushing the information
that is given later out to the right, e.g. "erro
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
>>
>>> I am more worried about variable length part pushing the information
>>> that is given later out to the right, e.g. "error: missing file '%s'
>>> prevents us from doing X". Cho
On Wed, Dec 10, 2014 at 11:00:18AM -0800, Junio C Hamano wrote:
> Two potential issues are:
>
> - Callers that ignore errors need to actively ignore errors with
>strbuf_release(&result.msg);
That was my first thought, too. If you want to do anything besides
report_error, you have to deal wi
Michael Haggerty writes:
> What if we go in the direction not of less infrastructure, but a little
> bit more? Like
>
> struct result {
> int code;
> struct strbuf msg;
> };
>
> int report_errors(struct result *result)
> {
> int co
On 12/04/2014 08:59 AM, Jeff King wrote:
> On Wed, Dec 03, 2014 at 01:38:58PM -0800, Jonathan Nieder wrote:
>> The allocation of a variable-sized buffer is a small overhead that I
>> don't mind incurring on error. In the non-error case, the caller
>> doesn't actually have to free the buffer, and i
On Tue, Dec 09, 2014 at 10:43:52AM -0800, Junio C Hamano wrote:
> > Unless we can do something clever with a set of global error strbufs or
> > something (i.e., that expand as needed, but the caller does not have to
> > free themselves, as they will get recycled eventually). That has its own
> > c
Jeff King writes:
> On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
>
>> I am more worried about variable length part pushing the information
>> that is given later out to the right, e.g. "error: missing file '%s'
>> prevents us from doing X". Chomping to [1024] is not a good
>>
On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > The only downside I can think of is that we may truncate the message in
> > exceptional circumstances. But is it really any less helpful to say:
> >
> > error: unable to open file: some-incredibly-long-fi
Jeff King writes:
> The only downside I can think of is that we may truncate the message in
> exceptional circumstances. But is it really any less helpful to say:
>
> error: unable to open file: some-incredibly-long-filename-aa...
>
> than printing out an extra 100 lines of "a"? And I mean
On Thu, Dec 04, 2014 at 03:52:45PM -0800, Junio C Hamano wrote:
> Yeah, that is what I meant. The earlier part will not go to waste no matter
> what happens to the discussion.
>
> I am not a fan of char[1024], if only because our error message may have
> to mention things whose length is not unde
Yeah, that is what I meant. The earlier part will not go to waste no matter
what happens to the discussion.
I am not a fan of char[1024], if only because our error message may have
to mention things whose length is not under our control, e.g. a filename
in the working tree, but I do share your con
On Thu, Dec 04, 2014 at 03:41:47PM -0800, Jonathan Nieder wrote:
> Junio C Hamano wrote:
> > Jonathan Nieder writes:
>
> >> Here's a draft for documentation on that.
> >
> > Thanks; looks reasonable; even if the discussion between you and
> > Peff took us to a slightly different direction than w
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Here's a draft for documentation on that.
>
> Thanks; looks reasonable; even if the discussion between you and
> Peff took us to a slightly different direction than what you
> described here, the earlier description of long established practice
>
Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Here's a draft for documentation on that.
>
> Thanks; looks reasonable; even if the discussion between you and
> Peff took us to a slightly different direction than what you
> described here, the earlier description of long established pract
Jonathan Nieder writes:
> Signed-off-by: Jonathan Nieder
> ---
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> -extern int copy_fd(int ifd, int ofd);
>>> +extern int copy_fd(int ifd, int ofd, struct strbuf *err);
>>
>> It is not limited to this single function, but what contract do we
On Thu, Dec 04, 2014 at 12:36:46AM -0800, Stefan Beller wrote:
> > Your solution adds a strbuf. That helps with context and stomping, but
> > loses readability and adds allocation.
>
> > If we changed the strbuf to a fixed-size buffer, that would help the
> > allocation issue. Some messages might
> Your solution adds a strbuf. That helps with context and stomping, but
> loses readability and adds allocation.
> If we changed the strbuf to a fixed-size buffer, that would help the
> allocation issue. Some messages might be truncated, but it seems
> unlikely in practice. It still loses readabi
On Wed, Dec 03, 2014 at 01:38:58PM -0800, Jonathan Nieder wrote:
> > What about a struct that has an errno-like value _and_ a fixed-size
> > buffer? I'm thinking something like:
> >
> > struct error {
> > int code;
> > char msg[1024];
> > };
>
> My experience with errno is that it is
Signed-off-by: Jonathan Nieder
---
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> -extern int copy_fd(int ifd, int ofd);
>> +extern int copy_fd(int ifd, int ofd, struct strbuf *err);
>
> It is not limited to this single function, but what contract do we
> envision this "error messages are gi
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Junio C Hamano wrote:
>>> By the way, this seems to address the same thing as sb/copy-fd-errno
>>> topic that has been cooking in 'pu'? Should we drop that other
>>> topic and use this one instead?
>>
>> Yes, please.
>
> OK.
>
> It felt strange t
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> By the way, this seems to address the same thing as sb/copy-fd-errno
>> topic that has been cooking in 'pu'? Should we drop that other
>> topic and use this one instead?
>
> Yes, please.
OK.
It felt strange that two people in a same office s
Hi,
Jeff King wrote:
> What about a struct that has an errno-like value _and_ a fixed-size
> buffer? I'm thinking something like:
>
> struct error {
> int code;
> char msg[1024];
> };
My experience with errno is that it is very hard to anticipate what
granularity to use with erro
On Wed, Dec 03, 2014 at 11:01:08AM -0800, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > -extern int copy_fd(int ifd, int ofd);
> > +extern int copy_fd(int ifd, int ofd, struct strbuf *err);
>
> It is not limited to this single function, but what contract do we
> envision this "error mes
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> -extern int copy_fd(int ifd, int ofd);
>> +extern int copy_fd(int ifd, int ofd, struct strbuf *err);
>
> It is not limited to this single function, but what contract do we
> envision this "error messages are given back to the caller via
> strbuf"
On Wed, Dec 3, 2014 at 12:02 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> This way, callers can put the message in context or even avoid
>> printing the message altogether.
>>
>> Currently hold_lock_file_for_append tries to save errno in order to
>> produce a meaningful message about
Junio C Hamano wrote:
> By the way, this seems to address the same thing as sb/copy-fd-errno
> topic that has been cooking in 'pu'? Should we drop that other
> topic and use this one instead?
Yes, please.
I'll give it an hour or two to collect more comments and then send a
reroll reflecting the
Jonathan Nieder writes:
> This way, callers can put the message in context or even avoid
> printing the message altogether.
>
> Currently hold_lock_file_for_append tries to save errno in order to
> produce a meaningful message about the failure and tries to print a
> second message using errno.
Jonathan Nieder writes:
> -extern int copy_fd(int ifd, int ofd);
> +extern int copy_fd(int ifd, int ofd, struct strbuf *err);
It is not limited to this single function, but what contract do we
envision this "error messages are given back to the caller via
strbuf" convention should give between t
31 matches
Mail list logo
