Mailing-List: contact dev-help@curator.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.incubator.apache.org
MIME-Version: 1.0
Reply-To: vines@apache.org
From: John Vines <vines@apache.org>
Date: Wed, 29 May 2013 16:59:28 -0400
Message-ID: 
 <CADczPYQNLFPr7SKYtQb1u2AKQ5bXNzCA7XxYVZ1xYR8Z6U0hcw@mail.gmail.com>
Subject: Curator-29 - Exception handling
To: dev@curator.incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b33da5ebd735704dde1aadc

--047d7b33da5ebd735704dde1aadc
Content-Type: text/plain; charset=ISO-8859-1

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.

--047d7b33da5ebd735704dde1aadc--