I'm on the fence about checked vs. unchecked, but I think Javadoc that declares what exceptions are thrown would help users figure out if they might want to catch something.
Additionally some of the ZkClient method semantics are confusing. For example, create() returns the path of the created node, but throws a (runtime) ZkNodeExistsException when the node already exists. Creating a node that already exists is a relatively non-exceptional circumstance IMHO. Wouldn't it be simpler to return the path to the client, essentially pretending that the creation succeeded? Also, is it correct that if you want to "use" a node that may not exist, you'd have to call create() and then wait for the node to actually be created via (in zkclient) waitUntilExists()? (Obviously the node can be removed before it is used, and that situation needs to be taken care of anyway.) Perhaps create() and waitUntilExists() should be combined, or offer a combined version. As a naive zk user a wrapper like that would remove a lot of error potential. Apologies if this is not the best place for zkclient API discussions. .. Adam On Thu, Oct 1, 2009 at 9:19 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > I think that another way to say this is that zkClient is going a bit for the > Spring philosophy that if the caller can't (or won't) be handling the > situation, then they shouldn't be forced to declare it. The Spring > jdbcTemplate is a grand example of the benefits of this. > > First implementations of this policy generally are a bit too broad, though, > so this should be examined carefully. > > On Thu, Oct 1, 2009 at 8:05 AM, Peter Voss <i...@petervoss.org> wrote: > >> 5) there's a lot of wrapping of exceptions, looks like this is done in >>> order to make them unchecked. Is this wise? How much "simpler" does it >>> really make things? Esp things like interrupted exception? As you mentioned, >>> one of your intents is to simplify things, but perhaps too simple? Some >>> short, clear examples of usage would be helpful here to compare/contrast, I >>> took a very quick look at some of the tests but that didn't help much. Is >>> there a test(s) in particular that I should look at to see how zkclient is >>> used, and the benefits incurred? >>> >> >> Checked exceptions are very painful when you are assembling together a >> larger number of libraries (which is true for most enterprise applications). >> Either you wind up having a general "throws Exception" (which I don't really >> like, because it's too general) at most of your interfaces, or you have to >> wrap checked exceptions into runtime exceptions. >> >> We didn't want a library to introduce yet another checked exception that >> you MUST catch or rethrow. I know that there are different opinions about >> that, but that's the idea behind this. >> >> Similar situation for the InterruptedException. ZkClient also converts this >> to a runtime exception and makes sure that the interrupted flag doesn't get >> cleared. There are just too many existing libraries that have a "catch >> (Exception e)" somewhere that totally ignores that this would reset the >> interrupt flag, if e is an InterruptedException. Therefore we better avoid >> having all of the methods throwing that exception. > > > > > -- > Ted Dunning, CTO > DeepDyve >
