curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: Exception throwing
Date Fri, 01 Aug 2014 20:06:15 GMT
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.com
> wrote:

> Like I said, if I could go back, I’d get rid of checked exceptions
> 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’d remove all checked exceptions entirely. I don’t
>> think there’s an objective answer here - it comes down to personal
>> preference, etc. I don’t see much value in touching nearly every file in
>> the library in order to do this. We’ve 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 touch
>> 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 also
>> 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
>>
>>
>

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