curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Blum (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-135) API Cleanup: Avoid throwing Exception
Date Thu, 09 Oct 2014 18:00:34 GMT

    [ 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)

Mime
View raw message