[
https://issues.apache.org/jira/browse/CURATOR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165442#comment-14165442
]
Scott Blum commented on CURATOR-135:
------------------------------------
I see both sides of it, but personally I tend to favor a less defensive style
of programming where you let exceptions propagate up and then make tactical
fixes based on production experience. That said, I do find this kind of coding
pattern difficult.
{code}
try {
client.create().creatingParentsIfNeeded().forPath(path, seedValue);
} catch ( KeeperException.NodeExistsException ignore ) {
// ignore
}
{code}
You can look at the javadoc for any of the methods in that create chain, and
none of them clue you in as to which exceptions might be thrown from this
particular fluent invocation. I'm not sure checked exceptions is the right
answer tho.
> API Cleanup: Avoid throwing Exception
> -------------------------------------
>
> Key: CURATOR-135
> URL: https://issues.apache.org/jira/browse/CURATOR-135
> Project: Apache Curator
> Issue Type: Improvement
> Reporter: Mike Drob
> Assignee: Jordan Zimmerman
>
> It would be nice if the API did not throw Exception in so many places and
> threw the more specific subclasses instead. We should scrub the API to
> improve the method signatures, possibly creating sub-tasks to do so on a
> module-by-module (or more granular) basis.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
