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
