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 <[email protected] > 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 <[email protected]> <[email protected]> > Reply: [email protected] <[email protected]>> > <[email protected]> > Date: August 1, 2014 at 2:32:07 PM > To: [email protected] <[email protected]>> > <[email protected]> > 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 > >
