curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Curator-29 - Exception handling
Date Wed, 29 May 2013 20:59:28 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message