Curator is now community driven so we should decide this as a community. That said, the entire Curator code-base throws Exception and only Exception.
-JZ On May 29, 2013, at 1:59 PM, John Vines <[email protected]> wrote: > Links to make things easier for people- > https://issues.apache.org/jira/browse/CURATOR-29 > https://github.com/Netflix/curator/issues/13 > > My issue is that the forPath interface throws an Exception. I can recognize > the point made that an exception is an exception is an exception and should > be a failure case. And Exceptions do make everything easier internally. But > it makes client writing a PITA. > > I think it boils down to not all failure cases being the same. Yes, there > are several that can be lumped into "Something between this process and > where you say Zookeeper is is broken", such as several of the > KeeperExceptions, as well as InterruptedException, and the others I can > spout off by running through the code. But there are also lighter > exceptions that should be reported seperately. I specifically mean things > like NoNodeException, NodeExistsExceptions, and InvalidACLException (not > sure about that last one, haven't played with curator for ACLs yet). They > should probably be rethrown as a simpler exception, but it should be > explicit in the interface so users know it's coming. > > I can understand implementation could be a bear with it, and/or this is not > a priority. If the latter, I don't mind working on it. But honestly I think > this makes for poor usability in a project that tries to make a difficult > to use project easier, which just doesn't seem right. > > But that's just my thought on the matter.
