On Mon, 21 Feb 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>
> > Proposal:
> >
> > Replace use of Error.pm module in Git.pm with either Exception::Class
> > based error class, or using 'carp'/'croak' from Carp, or both by adding
> > an option to set error handler in 'Git' class (like e.g. in 'CHI'
> > module on CPAN).
>
> Personally, I was never a big fan of the syntax magic with Error.pm, but I
> refrained from commenting on it as I am not heavily involved in that part
> of the system. If we are going to change things so that everybody uses a
> more traditional "eval {}; if ($@) { ... }", it would be a welcome change
> from my point of view.
Structured exceptions are usually better than 'die <string>' if
you need to examine error in more detail and act on this detail:
http://www.modernperlbooks.com/mt/2010/10/structured-data-and-knowing-versus-guessing.html
http://www.modernperlbooks.com/mt/2010/08/the-stringceptional-difficulty-of-changing-error-messages.html
http://www.modernperlbooks.com/mt/2010/07/dont-parse-that-string.html
I think that is why Git.pm uses Error module (which seemed like a good
choice in 2006), and it is why I propose using Exception::Class, perhaps
as an option.
> > Migration plan:
>
> Do we even need one?
>
> As far as an external caller is concerned, it would have been expecting us
> to throw an exception by dying, and it wouldn't have mattered if it used
> Error.pm or "eval { $call_to_Git_pm }; if ($@) {...}", I think.
Well, it depends if external scripts use try_git_cmd sugar... and whether
they try to act on details of caught exception.
Also if Git->repository would return 'undef' on failure instead of throwing
an exception, this would require changes to external scripts.
--
Jakub Narebski
Poland
--
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