| Re: [jgit-dev] Git API Exceptions |
Hi,
I also agree. Here is why:
>> It is impossble to add new checked exceptions to JGit commands without
>> breaking the
>> API. See http://egit.eclipse.org/r/#change,4809
>>
>> Shouldn't all call() throw a GitAPIException so callers can understand that
>> they
>> need to catch it in case something new comes along?
The idea behind GitAPIException was to be a superclass of all checked
exceptions API commands may throw. This should enable beginner-level users
of the API to write code with minimal lines spent for error handling. Just
catch only GitAPIException, throw an error when you get it and your
code should compile.
No need to understand and catch the dozens of specific exceptions when you start
your first GitAPI program.
Of course anybody writing serious code will want to deal with the
specific exceptions. And if you start to throw new checked exceptions
then I guess you expect users of the API to catch it.
By introducing the rule that all checked exceptions have to be
subclasses of GitAPIExceptions we have the chance to throw
new checked exceptions without breaking the builds of our users.
That's a good thing. The bad thing is that maybe nobody will
start handling your new exception because the old code (not handling
the new exception) is still compiling and working. I prefer
not breaking the other users builds and having the freedom to
introduce new exceptions when we need them.