This is a philosophical issue. If Curator had no throws clauses at all it would be the same. So, getting rid of all the “throws Exception” statements wouldn’t help this. In my opinion, this is all baked into Curator and not worth changing. But, of course, if you can convince the rest of the community maybe we can change it. I’ve reopened CURATOR-135. If you folks can convince the community and one of the other committers than it can get done.
-Jordan From: John Vines <[email protected]> Reply: [email protected] <[email protected]>>, [email protected] <[email protected]>> Date: August 1, 2014 at 3:40:25 PM To: [email protected] <[email protected]>> Cc: Mike Drob <[email protected]>> Subject: Re: Exception throwing It's not a matter of it being a bug, it's a matter of usability. Because every single method just throws Exception it gives me, as a user, absolutely zero inclination at writing time to figure out what sort of failures can happen. And the complete lack of javadocs compound this issue. This has been my biggest issue with Curator. Yes, there are some unrecoverable errors. But not all of them are, such as a subset of the KeeperExceptions around node state, security, and versions. I could be sold on a split, where those type of items are exposed and then the critical ones you keep mentioning are Runtime. But as much as I dislike generic Exceptions for everything, forcing users to catch RuntimeExceptions to do proper exception handling for known and well defined exceptions is an awful practice to put people though. On Fri, Aug 1, 2014 at 3: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]> > Reply: [email protected] <[email protected]>> > Date: August 1, 2014 at 2:32:07 PM > To: [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 >
