Re: [PATCH 3/9] Prepare the builtins for a libified merge_recursive()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

On Fri, 1 Jul 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> > A truly libified function does not die() just for fun.
> >> 
> >> The sentence is wasting bits.  After all, a helper function in
> >> run-once-and-exit program does not die() just for fun, either.
> >
> > This sentence does not so much target *you* personally as audience, but
> > the occasional reader of the log who wonders: "Why don't we just call
> > die()? We would not have to worry about passing back the return value
> > through all those long call chains..."
> 
> I was (and I am still) reacting mostly to "just for fun".

Yeah, sorry, that part was lost on me.

> > Even more natural is it to guess that the code will call error(), just
> > like we do almost everywhere else.
> > ...
> >> But that does not mesh very well with the stated objective of the
> >> patch.
> > ...
> > I could imagine that you wanted even more fine-grained control, where we
> > have a range of return values indicating different error conditions.
> 
> I personally don't.  I was pointing out the discrepancy between what
> the introduction says, i.e. "this way is way more flexible for the
> callers when they want to do their own error handling", and what the
> code actually does.  If the explanation said "This series does not
> give the full flexibility potential callers may desire yet, but at
> least gives enough flexibility to do 'I do not want the called
> function to die, but append my own error message before I die
> myself'.", that is certainly an understandable stance to take, I
> would say.

Ah, but the message did not say "error message handling", but "error
handling". With my limited command of the English language, I tried to
convey that this patch allows the callers to do something when the called
operation reported an error. Previously they did not get the chance.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]