curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Curator-29 - Exception handling
Date Wed, 29 May 2013 21:03:17 GMT
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 <vines@apache.org> 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.


Mime
View raw message