Re: [PATCH][GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocks

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

 



On 23/05/12 12:02, Subho Banerjee wrote:
> Hi,
> The semantic
>>        <fail> unless <noun>
> works well when the <fail> part of the code is a singular statement.
> But it is of ungainly when there are a couple of statements to be
> executed as a block. In this case, I believe that a the conjunctive
> ,,or''/,,and'' statement makes more sense. In the sense -
>                  <verb1> or <die_gracefully1> and <die_gracefully2>
> I believe this is easier to read compared to -
>                  <die_gracefully1> and <die_gracefully2> unless <noun>
> especially if you have a larger block of commands to execute in case
> of the failure. I believe the easiest to read would be a classical C
> styled if() block, but that would make the code more "verbose" :-)

To be honest, I drop straight back to C-style if() statements as soon as
I have to start thinking consciously about precedence rules (where by
"thinking" I mean "creating bugs then failing to see them under my
nose").  I also don't think anyone would object if you wanted to stick
with classic if() statements everywhere - colloquialisms are supported,
not required :)

So long as you're aware this is an exception to the rule about matching
the style of surrounding code, I'm personally quite relaxed about fixing
these specific instances.  If nobody else has any opinions, maybe hold
off and see how much change you're planning to make elsewhere?  No sense
getting too attached to code you might have to throw away.

	- Andrew
--
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]