Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Exceptions thrown by GitCommand.call

Hi,

> Some subclasses of GitCommand have call() signatures that throw only
> GitApiException (CherryPick, Revert), some throw only JGitInternalException
> (AddNote, Blame, DeleteTag), and others throw a mix of exception types.
> Going forward, is there a pattern that new commands should follow?  Just
> mirror the signature of GitCommand and declare a throws of Exception only?

I think that checked exceptions should be subclass of GitApiException.
Unchecked exceptions should either be the exceptions of lower layers
which caused the problem (e.g. IOExceptions during file-system access)
or, if we want to wrap the unchecked exception, of type
JGitInternalException.

For me the situation for checked exceptions is clear - I have to throw
a subclass of GitApiException. The only decision for me as developer
of a new command is when my Command-code has to deal with unchecked
excpetions for the lower levels. Should I wrap them inside
JGitInternalExcpetions or should I let them just bubble up as they
are.
Or what is if the command decides on it's own it wants to throw a
unchecked exeception without having a unchecked exception from lower
layers which caused this. Then I would throw JGitInternalException.
E.g. when during CheckoutCommand.call() the RefUpdate returns
return-codes which completely unexpected. The command-code does not
know how to deal with it and the user of our API also has no clue. Not
a situation where we should throw a checked exception forcing every
user catch and handle it -> therefore we throw a
JGitInternalException.

> Looking at the documentation of GitApiException, it would seem that maybe
> that should be the exception class to throw consistently for newly added
> commands.

I agree: Best is to throw a GitApiExceptions. Don't throw checked
exceptions not of that type.

> This is just a general question of what is the best practice that we may
> want to document and follow for consistency as new Git commands are added.

+1

Ciao
  Chris


Back to the top