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 <[email protected] > wrote: > Like I said, if I could go back, I’d get rid of checked exceptions > entirely. > > -JZ > > From: Mike Drob <[email protected]> <[email protected]> > Reply: Mike Drob <[email protected]>> <[email protected]> > Date: August 1, 2014 at 2:54:47 PM > To: Jordan Zimmerman <[email protected]>> > <[email protected]> > Cc: [email protected] <[email protected]>> > <[email protected]> > 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 < > [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 >> >> >
