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 19:54:27 GMT
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