From: "Martin Ågren" <martin.agren@gmail.com>
To: "Оля Тележная" <olyatelezhnaya@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [RFC 0/4] ref-filter: remove printing from formatting logic
Date: Tue, 13 Mar 2018 20:26:23 +0100 [thread overview]
Message-ID: <CAN0heSp-Vsvr95zc3J0iokRMJt74pxFH7OsoiR_3gnkMxpAAKw@mail.gmail.com> (raw)
In-Reply-To: <CAL21BmkmXKzdwYHu1pNxuHhaxqei4ekVbutbuv2jmv6=GgcG_A@mail.gmail.com>
Hi Olga
On 13 March 2018 at 11:25, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
> 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
next prev parent reply other threads:[~2018-03-13 19:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 10:25 [RFC 0/4] ref-filter: remove printing from formatting logic Оля Тележная
2018-03-13 19:26 ` Martin Ågren [this message]
2018-03-14 13:44 ` Оля Тележная
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN0heSp-Vsvr95zc3J0iokRMJt74pxFH7OsoiR_3gnkMxpAAKw@mail.gmail.com \
--to=martin.agren@gmail.com \
--cc=git@vger.kernel.org \
--cc=olyatelezhnaya@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).