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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 17, 2008, 14:33 UTC
Message-ID: <200806171633.26864.jnareb@gmail.com>
In-Reply-To: <4857C469.1000401@gmail.com>

Lea Wiemann wrote:

> Junio C Hamano wrote:

Show 7 quoted lines

> > [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).

Show 10 quoted lines

> 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