Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Received-SPF: pass (nike.apache.org: domain of mdrob@cloudera.com designates
 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.53dbf0c0.1849c29b.665b@Jordans-MacBook-Pro.local>
References: 
 <CAFAMeY+hPnbkKHkhgAjNh5Rv_3gTtmJSZFkecHFXUKkH=_hdLg@mail.gmail.com>
 <etPan.53dbef6f.24e99dd7.665b@Jordans-MacBook-Pro.local>
 <CAFAMeY+-Ut2MJNdUF6zR+M+eh0VTQQFJ7NaLzc3HL4NF9pFZhg@mail.gmail.com>
 <etPan.53dbf0c0.1849c29b.665b@Jordans-MacBook-Pro.local>
From: Mike Drob <madrob@cloudera.com>
Date: Fri, 1 Aug 2014 15:06:15 -0500
Message-ID: 
 <CAFAMeYJ4ovJFqCrVbZadoWosWK2PsdQisePQ2_d3Ga6spWADgQ@mail.gmail.com>
Subject: Re: Exception throwing
To: Jordan Zimmerman <jordan@jordanzimmerman.com>
Cc: dev@curator.apache.org
Content-Type: multipart/alternative; boundary=001a11348abc1d58d504ff96eddf

--001a11348abc1d58d504ff96eddf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So what's preventing us from changing this going forward? It's software, we
have the ability to fix it; if something can be improved and we are able to
improve it, then we can go ahead and do that.


On Fri, Aug 1, 2014 at 2:55 PM, Jordan Zimmerman <jordan@jordanzimmerman.co=
m
> wrote:

> Like I said, if I could go back, I=E2=80=99d get rid of checked exception=
s
> entirely.
>
> -JZ
>
> From: Mike Drob <madrob@cloudera.com> <madrob@cloudera.com>
> Reply: Mike Drob <madrob@cloudera.com>> <madrob@cloudera.com>
> Date: August 1, 2014 at 2:54:47 PM
> To: Jordan Zimmerman <jordan@jordanzimmerman.com>>
> <jordan@jordanzimmerman.com>
> Cc: dev@curator.apache.org <dev@curator.apache.org>>
> <dev@curator.apache.org>
> Subject:  Re: Exception throwing
>
>  So why declare that we throw exceptions instead of just throwing
> everything as a RuntimeException (or subclass thereof)?
>
>
> On Fri, Aug 1, 2014 at 2:49 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>>  -1 (binding)
>>
>>  If I could go back I=E2=80=99d remove all checked exceptions entirely. =
I don=E2=80=99t
>> think there=E2=80=99s an objective answer here - it comes down to person=
al
>> preference, etc. I don=E2=80=99t see much value in touching nearly every=
 file in
>> the library in order to do this. We=E2=80=99ve had maybe 2 or 3 requests=
 in the
>> many years that Curator has exists. This suggests that the overwhelming
>> majority accept the current exception semantics. If you can point to an
>> actual bug that this causes that would be helpful.
>>
>>  -Jordan
>>
>> From: Mike Drob <madrob@cloudera.com> <madrob@cloudera.com>
>> Reply: dev@curator.apache.org <dev@curator.apache.org>>
>> <dev@curator.apache.org>
>> Date: August 1, 2014 at 2:32:07 PM
>> To: dev@curator.apache.org <dev@curator.apache.org>>
>> <dev@curator.apache.org>
>> Subject:  Exception throwing
>>
>>  I'd like to revisit the discussion around always throwing Exception in
>> the
>> API. There were two JIRA issues - CURATOR-135 and CURATOR-29 - that touc=
h
>> on this subject, but I think there is a good conversation to be had.
>>
>> I understand the suggestions that if an exception is thrown, we are in a
>> bad state, regardless of the type of exception. However, throwing
>> Exception
>> comes with some unfortunate Java baggage...
>>
>> By declaring thrown Exception, we force consumers to also catch
>> RuntimeExceptions instead of letting them propagate as they normally
>> would.
>> In some cases, the calling code may need to attempt roll-back semantics,
>> or
>> retry outside of what Curator provides, or something else that we haven'=
t
>> thought of.
>>
>> I'd like to propose replacing much of the thrown Exception methods with
>> CuratorException. This will still carry the connotation that it doesn't
>> matter what kind of exception we encounter, they're all bad. It will als=
o
>> be backwards compatible with the previous API, since users will still be
>> able to catch Exception in their calling code. And it has the advantage =
of
>> separating checked exceptions from unchecked ones, so that users don't
>> unintentionally catch something unrelated.
>>
>> Thoughts?
>>
>> I tried looking for more details behind the design decision to always
>> throw
>> Exception, but wasn't able to find them. If they're already documented,
>> I'd
>> love to be pointed at the wiki or site, or a mailing list thread will do
>> in
>> a pinch.
>>
>> Thanks,
>> Mike
>>
>>
>

--001a11348abc1d58d504ff96eddf--