zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: feedback zkclient
Date Thu, 01 Oct 2009 18:06:36 GMT
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 <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.

View raw message