curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: Exception throwing
Date Fri, 01 Aug 2014 20:35:18 GMT
I can’t think of a good reason to do it. It’s fine the way it is now and isn’t causing
any problems. It would be very disruptive to change this for little benefit.


From: Mike Drob <>
Reply: Mike Drob <>>
Date: August 1, 2014 at 3:06:35 PM
To: Jordan Zimmerman <>>
Cc: <>>
Subject:  Re: Exception throwing  

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 <> wrote:
Like I said, if I could go back, I’d get rid of checked exceptions entirely.


From: Mike Drob <>
Reply: Mike Drob <>>
Date: August 1, 2014 at 2:54:47 PM
To: Jordan Zimmerman <>>
Cc: <>>
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 <> 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.


From: Mike Drob <>
Reply: <>>
Date: August 1, 2014 at 2:32:07 PM
To: <>>
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.


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.


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