Subject: Re: [PATCH/RFC] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)

From: Jeff King <[email-masked]>
Date: Thu, 4 Dec 2014 19:01:28 -0500

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 under our control, e.g. a filename
> in the working tree, but I do share your concern that "strbuf"-approach
> calls for more boilerplate. I offhand do not have a magic silver bullet for
> it, though.

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-aaaaaa...

than printing out an extra 100 lines of "a"? And I mean the "..."
literally. I think mkerror() should indicate the truncation with a
"...", just so that it is clear to the user. It should almost never
happen, but when it does, it can be helpful to show the user that yes,
we know we are truncating the message, and it is not that git truncated
your filename during the operation.

Is this truncation really a concern, and/or is there some other downside
I'm not thinking of?

-Peff