All of lore.kernel.org
 help / color / mirror / Atom feed
From: demerphq <demerphq@gmail.com>
To: Subho Banerjee <subs.zero@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Tim Henigan <tim.henigan@gmail.com>, git <git@vger.kernel.org>
Subject: Re: Git.pm
Date: Thu, 10 May 2012 17:54:38 +0200	[thread overview]
Message-ID: <CANgJU+W-FJZRtu_4si7nr96KfNe2rzaiUaDC0GiK_WixudvcxA@mail.gmail.com> (raw)
In-Reply-To: <CAB3zAY3VHtUobJfJ7=nSKb_6uJOXLGVHzR18qV6txPkzf54cDw@mail.gmail.com>

On 10 May 2012 15:19, Subho Banerjee <subs.zero@gmail.com> wrote:
> Hello,
> I have started looking into how the error catching mechanism
> implemented right now. I have looked into the more modern error
> catching/throwing mechanisms in use in perl, and I am of the opinion
> that Try::Simple would probably be the best candidate for being the
> new error catching mechanism. I also wanted to discuss some aspects of
> the changes to be made -
> ------- Replacing the Error::Simple stuff should be relatively
> straightforward. It can be achieved with simple changes to the syntax
> of the perl module itself.
>
> ------- What I feel will be more complicated, and will require some
> discussion before it is implemented is the Git::Error module. This has
> modified some of the code in the original Error module and is used
> only when there are calls made to the git system command. Using the
> Try::Tiny will mean that this can be simplfied to a very large extent.
> As a mater of fact I am in favor of getting rid of this completely and
> implementing whatever is required in the Git.pm as required. Because
> the Try::Tiny module no longer requires exception objects to be
> thrown. Its just simply passing strings around.
>
> This I believe is a big decision, and I would like to hear what you
> guys have to say before I actually get along changing and playing
> around with stuff inside the code.

Personally I would prefer it just does error handling like any other
standard Perl code does: either return false, or dies with a useful
error message. One of the things I find annoying about Git.pm is it
forces its authors non-standard preferences for exception handling
onto its users.

Any other approach forces people to use the exception framework you
have chosen. Which is just a pain in the ass.

Similar logic for Try::Tiny. Why bother with it? It is pretty close to
a fancy way to write eval { ...; 1 } or do { .... };  It is just one
more module for people to misunderstand, and then make bugs with.

Why require people coding on your module to learn a new way to eval code?

Yes I know in some circles these are probably controversial points,
but in all the core, heavily used Perl code I know of none of it uses
either exception objects nor Try::Tiny. I think there is a reason why.

So think carefully. Look at DBI.pm for guidance. That module is
probably the single most stable, well maintained and widely used
module in Perl. And it does none of the tricks you discuss here.

Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

  parent reply	other threads:[~2012-05-10 15:54 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  4:15 Git.pm Subho Banerjee
2012-04-26 18:41 ` Git.pm Randal L. Schwartz
2012-04-26 18:58 ` Git.pm Tim Henigan
2012-04-26 20:10   ` Git.pm Subho Banerjee
2012-04-26 20:31     ` Git.pm Jonathan Nieder
2012-05-10 13:19       ` Git.pm Subho Banerjee
2012-05-10 15:16         ` Git.pm Jonathan Nieder
2012-05-10 15:54         ` demerphq [this message]
2012-05-10 16:18           ` Git.pm Subho Banerjee
2012-05-10 17:22             ` Git.pm demerphq
2012-05-10 16:20           ` Git.pm Junio C Hamano
2012-05-10 17:38             ` Git.pm demerphq
2012-05-10 20:55         ` Git.pm Andrew Sayers
2012-05-11  8:27           ` Git.pm demerphq
2012-05-11 16:56         ` Git.pm Randal L. Schwartz
2012-05-11 18:10           ` Git.pm Junio C Hamano
2012-05-19  7:08             ` [PATCH][GIT.PM 1/3] Ignore files produced from exuberant-ctags Subho Sankar Banerjee
2012-05-19  7:08               ` [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 Subho Sankar Banerjee
2012-05-19  9:38                 ` Andrew Sayers
2012-05-23 11:02                   ` Subho Banerjee
2012-05-23 19:36                     ` Andrew Sayers
2012-05-19  7:08               ` [PATCH][GIT.PM 3/3] Perl code uses eval{}/die instead of Error::Simple and Git::Error::Command Subho Sankar Banerjee
2012-04-26 19:17 ` Git.pm Junio C Hamano
2012-04-26 19:59 ` Git.pm Sam Vilain
  -- strict thread matches above, loose matches on Subject: below --
2008-11-19 17:56 Git.pm nadim khemir
2008-11-20  8:34 ` Git.pm Petr Baudis
2008-11-20 13:07   ` Git.pm Petr Baudis
2008-11-23 19:58   ` Git.pm nadim khemir
2008-12-07 17:39     ` Git.pm nadim khemir
2008-11-21  2:56 ` Git.pm Jakub Narebski
2008-11-23 20:09   ` Git.pm nadim khemir

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANgJU+W-FJZRtu_4si7nr96KfNe2rzaiUaDC0GiK_WixudvcxA@mail.gmail.com \
    --to=demerphq@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=subs.zero@gmail.com \
    --cc=tim.henigan@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.