Re: [RFC 0/4] ref-filter: remove printing from formatting logic
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- Mar 13, 2018, 19:26 UTC
- Message-ID
- <CAN0heSp-Vsvr95zc3J0iokRMJt74pxFH7OsoiR_3gnkMxpAAKw@mail.gmail.com>
- In-Reply-To
- <CAL21BmkmXKzdwYHu1pNxuHhaxqei4ekVbutbuv2jmv6=GgcG_A@mail.gmail.com>
Hi Olga
On 13 March 2018 at 11:25, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
Show 17 quoted lines
> The main idea of the patch is, if you want to format the output by > ref-filter, you should have an ability to work with errors by yourself > if you want to. > So I decided not to touch signature of show_ref_array_item(), but to > move all printing (I mean errors) to it. So that we could invoke > format_ref_array_item() and be sure that we cold handle errors by > ourselves. > > The patch is not finished, but I decided to show it to you. There are > still many places where we could die in the middle of formatting > process. But, if you like the general idea, I will finish and re-send > it. > > Another question is about verify_ref_format(). Do we need to allow its > users also to manage errors by themselves? I left the old scenario, > printing everything in verify_ref_format() and die. If you have better > ideas, please share them.
I think it is a good idea to stop die-ing in "libgit". This seems like a good way of achieving that, or isolating the issue. Do you have any particular use-case for this, i.e., are you setting up the stage for a patch "5" where you add a new user of one of these?
I do wonder whether a helper function to call strbuf_addstr() and return -1 would be a good idea though. I mentioned it in patch 2, then with patches 3 and 4, it started to seem like a reasonably good idea. It would be a shame if this sort of "boilerplate" for handling errors could have an impact on code clarity / obviousness.
Another issue is whether passing NULL for an error-strbuf should be a way of saying "I don't care; die() so I do not have to". Well, right now I guess passing NULL would indeed terminate the program. ;-) Such a construct might be another reason for providing error_strbuf_addstr()... Of course, it also means we keep die-ing in libgit..
I feel I'm just talking out loud. Maybe you find my input useful.
Martin