Hello Yves,
I am aware of that. But you see the problem is that using eval/warn/do
is that the $@ has to be localized every time eval is called. From my
understanding of how the Try::Tiny package works, this is exactly what
happens. So we are just calling a simple eval statement but in a block
where the $@ is handled properly, which is eventually what we would
have to do if we wrote it ourselves(Though I am not sure about how DBI
does it, I will have a look into that). And that is why I arrived in
favor of the Try::Tiny module in the first place. Well, that and the
ability to throw exception objects if required.
Cheers,
Subho.
On Thu, May 10, 2012 at 9:24 PM, demerphq <demerphq@xxxxxxxxx> wrote:
> On 10 May 2012 15:19, Subho Banerjee <subs.zero@xxxxxxxxx> 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/"
--
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