Bug 366914

Description Robin Rosenberg 2011-12-16 00:49:55 EST

Quoting from the mailing list

Robin:
    >> 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?

Christian Halstrick:

    I also agree. Here is why:

    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.