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
