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
--
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
