Re: [1.8.0] perl/Git.pm: moving away from using Error.pm module

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 21 Feb 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> 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