Not to harp on this ;-) but this sounds like something that would be a
very helpful addition to the README.
Ted Dunning 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.
