|Re: [jgit-dev] Git API Exceptions|
Hi, >> 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? 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.
Back to the top