zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: feedback zkclient
Date Thu, 01 Oct 2009 16:19:44 GMT
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 <info@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message