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