Re: [PATCH] gitweb: return correct HTTP status codes

[Jakub Narebski <jnareb@gmail.com>]

Lea Wiemann wrote:
> Junio C Hamano wrote:
 
> > [Gitweb's error handling:] isn't it possible for you to unconfuse
> > yourself in a slow path and  figure out exactly why it failed?
> > 
> >         unless (open $fd, '-|', ls-tree $base -- $path) {
> >                 # Oh, an error?  why?
> >                 if (!object_exists($base)) {  [...]
> >                 } elsif (!is_a_treeish($base)) {  [...]

BTW. you can catch such errors on close(), not on open(), my mistake.
On open you can catch only fairly fatal errors (5xx category I think).
 
> That's possible, but the API I'm writing is designed the other way 
> round: First, get the hash & type of $base; if it fails or the type is 
> wrong, die accordingly.  Then pass the hash you got into whatever call 
> to git, and if that fails, you can quite safely assume that something 
> serious went wrong.  (The example above has an additional $path to deal 
> with, but you get the idea.)
> 
> IOW, the strategy is "don't let the git binaries resolve any object 
> names for you", which should make both error handling and caching a lot 
> easier.

But that means checking arguments in the "fast path", which means
additional calls to git commands in the _common_ case, not only in
the case of errors.  I think that even with caching it is not a good
idea.

I'll try to come with example implementation using Error.pm and Git.pm
-- 
Jakub Narebski
Poland